perm filename MSG.MSG[X3,LSP]12 blob
sn#840724 filedate 1987-06-01 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂09-Oct-86 0616 jjohnson@mitre.ARPA ANSI X3J13 committee
Received: from MITRE.ARPA by SAIL.STANFORD.EDU with TCP; 9 Oct 86 06:15:52 PDT
Date: Thu, 9 Oct 86 09:14:26 edt
From: jjohnson@mitre.ARPA (Jerry Johnson)
Full-Name: Jerry Johnson
Message-Id: <8610091314.AA20136@mitre.ARPA>
Organization: The MITRE Corp., Washington, D.C.
To: common-lisp-request@su-ai.ARPA, mathis@b.isi.edu, rpg@sail.stanford.edu,
x3j13@sail.stanford.edu
Subject: ANSI X3J13 committee
Cc: jjohnson@mitre.ARPA
Greetings to all recipients of this message. I would appreciate your including
me on any correspondence concerning the standardization of Common Lisp within
ANSI and any other countries contributions to this ISO effort since I
am MITRE's representative on the X3J13 committee.
Sincerely,
Jerry Johnson
MITRE Corporation
AI Center
Mail Stop W418
1820 Dolley Madison Blvd
McLean, VA 22102
703-883-7173
∂09-Oct-86 1136 RPG Greetings
To: x3j13@SAIL.STANFORD.EDU
I am sending this message to reassure you that the X3J13
mailing list exists. The net address is:
x3j13@sail.stanford.edu
and the request address is
x3j13-request@sail.stanford.edu
-rpg-
∂10-Oct-86 1547 @REAGAN.AI.MIT.EDU:Hewitt@XX.LCS.MIT.EDU Meeting conflict
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Oct 86 15:47:04 PDT
Received: from DUE-PROCESS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 6231; Fri 10-Oct-86 18:44:00 EDT
Date: Fri, 10 Oct 86 18:44 EDT
From: Carl Hewitt <Hewitt@XX.LCS.MIT.EDU>
Subject: Meeting conflict
To: x3j13@SAIL.STANFORD.EDU
cc: Hewitt@XX.LCS.MIT.EDU
Message-ID: <861010184419.6.HEWITT@DUE-PROCESS.AI.MIT.EDU>
Folks,
I will be able to attend the next meeting on December 10 and 11 but not Dec.
12 because I have two scheduling conflicts on the 12th (it's my birthday and I
have to be present at another conflicting meeting on Friday the 12th).
--Carl
∂27-Oct-86 0653 MATHIS@ADA20.ISI.EDU X3J13 Meeting Dallas Dec 10-12
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 86 06:53:28 PST
Date: 27 Oct 1986 06:30-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: X3J13 Meeting Dallas Dec 10-12
From: MATHIS@ADA20.ISI.EDU
To: X3J13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU]27-Oct-86 06:30:46.MATHIS>
The second meeting of X3J13 will be held from 1pm, Wednesday,
December 10, 1986, until noon, Friday, December 12, 1986, at the
Sheraton Park Central in Dallas, Texas. Arrangements have been
made by Ellen Waldrum of Texas Instruments.
Many aspects of these early meetings are attempts to determine
the best things for this committee. There was some feeling that
this three day format was better than a two day format from both
travel and work perspectives. Having the meeting in a hotel makes
somethings easier, but it also makes the meal service more
expensive. TI graciously offered to help offset some of these
costs, but I thought that was the wrong precedent to be setting.
At the first meeting, it seemed that most people brought lunches
back to the meeting room so they could keep discussing various
issues; that is why we arranged a lunch for Thursday. At every
other TI sponsored meeting I have ever attended (once before)
there was an informal dinner (everyone ordering from the menu and
paying their own) at the Trail Dust (which is good and very
informal). We could make these arrangements for Wednesday night.
All of these food arrangements are optional.
Other aspects of the meeting (agenda, discussion papers, etc.)
will be covered in subsequent messages. -- Bob Mathis
The following is from Ellen Waldrum:
X3J13 December Meeting Registration Form; mail to:
Beverly Williams
Texas Instruments
P.O. Box 655474
MS 3651
Dallas, Texas 75265
A block of rooms is available at the Sheraton Park Central. The
rate will be $60 a night (plus tax). Please check the
appropriate dates and supply a credit card number if you wish to
have the room guaranteed. Coffee, juice, breakfast rolls, and
fruit will be available for the morning sessions and coffee and
soft drinks will be available for the afternoon sessions. Lunch
has been arranged for the Dec. 11 meeting. The cost per person
for this food service is $25. Please include a check for this
amount with the registration form if you wish to partake. Delta
Airlines has agreed to give participants a 40% discount.
Unfortunately, the reference number needed for reservations is
not available yet. It will be posted to the X3J13 mailing list
as soon as it is known. There has been some interest expressed
in having a group dinner at the Trail Dust the evening of Dec.
10 with an extra cost. If enough people want to participate,
reservations will be made. If you are interested, please note
this in the appropriate space below. If you have questions about
room or airline reservations, please call Beverly at
214-997-2108. Questions of a more general nature about the
arrangements should be directed to Ellen Waldrum at 214-995-6716
or net mail address Waldrum%TI-CSL@CSNET-RELAY.
Name:
------------------------------------------------------
Institution:
----------------------------------------------
Street Address:
--------------------------------------------
City: State: Phone:
----------------- ---- ----------------
Reservations: Dec. 9: Dec. 10: Dec. 11:
----- ----- -----
Credit Card: AE MC Visa Number:
--- --- --- ---------------------
Food Service: Yes No
--- ---
(Please make check payable to Texas Instruments)
Dinner at Trail Dust: Yes No
---- ----
The room rate is only guaranteed for reservations made before
November 17 so please mail this form as soon as possible.
∂05-Nov-86 0723 MATHIS@ADA20.ISI.EDU x3j13 second mailing
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Nov 86 07:23:18 PST
Date: 5 Nov 1986 07:14-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: x3j13 second mailing
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Nov-86 07:14:06.MATHIS>
I just sent out in US mail the second x3j13 mailing. In it I
said you should also have seen it on this electronic address.
Due to a computer problem (which you don't want to hearabout) I
am unable to send you the total information electronically; I am
however still able to communicate somewhat on the net.
If you have anything you want sent out before the next meeting I
should have it by November 14. In this case hardcopy that I
could photocopy would be helpful.
Remember to send in your hotel reservations for the Dallas
meeting.
-- Bob
∂14-Nov-86 1137 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Delta reference number
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 14 Nov 86 11:36:55 PST
Received: from ti-csl by csnet-relay.csnet id af01601; 13 Nov 86 8:10 EST
Received: from Puff (puff.ARPA) by tilde id AA04521; Wed, 12 Nov 86 16:05:10 cst
To: x3j13@SU-AI.ARPA
Cc: waldrum%ti-csl.csnet@RELAY.CS.NET
Subject: Delta reference number
Date: 12-Nov-86 15:59:39
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2741205578@Puff>
I had just sent the previous message when my phone rang.
Of course it was Beverly calling with the number I had
just told you was not available yet. To take advantage
of the Delta Airlines discount, you must make your
reservations through the Delta convention desk. The
phone number is 800-241-6760 and the reference file
number is B0238. We are listed with them as the
Computer Science Show. This discount is only good for
reservations made at least seven days in advance and
there are no penalties for cancellation. If you have
any questions or problems, please call Beverly or me
or send mail (Waldrum%ti-csl@csnet-relay).
-- Ellen
∂14-Nov-86 1136 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET December Meeting
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 14 Nov 86 11:36:26 PST
Received: from ti-csl by csnet-relay.csnet id ae01601; 13 Nov 86 8:08 EST
Received: from Puff (puff.ARPA) by tilde id AA03964; Wed, 12 Nov 86 15:49:14 cst
To: x3j13@SU-AI.ARPA
Cc: waldrum%ti-csl.csnet@RELAY.CS.NET
Subject: December Meeting
Date: 12-Nov-86 15:43:45
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2741204624@Puff>
If you are not able to mail your form in time to meet the
November 17 deadline and wish to make a reservation, you
should call Beverly Johnson at 214-997-2108 and give her
the pertinent information. If you do call Beverly, please
send the form anyway as verification.
The Delta airlines reference number is still not available.
All of the paperwork is done but Delta has not provided this
bit of pertinent information yet. It will be posted as soon
as we get it and Beverly will be calling those of you who have
already inquired.
-- Ellen
∂25-Nov-86 1302 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Reservation confirmation
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Nov 86 13:02:34 PST
Received: from ti-csl by csnet-relay.csnet id ad04601; 25 Nov 86 15:42 EST
Received: from Puff (puff.ARPA) by tilde id AA23037; Tue, 25 Nov 86 13:32:15 cst
To: x3j13@SU-AI.ARPA
Cc: ellen%Puff%ti-csl.csnet@RELAY.CS.NET
Subject: Reservation confirmation
Date: 25-Nov-86 13:28:28
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2742319706@Puff>
I have received reservation forms from the following
people:
Beckerle, Michael Hadden, George
Boelk, Mary Haflich, Steve
Brown, Gary Hewitt, Carl
Cugini, John Kiczales, Gregor
Daniels, Andrew Loeffler, David
Dussud, Patrick Margolin, Barry
Dabrowski, Christopher Perdue, Crispin
Ennis, Susan Rand, Douglas
Fahlman, Scott Rosenking, Jeffrey
Foderaro, John Wegman, Mark
Gabriel, Richard Wieland, Alexis
The following people have made reservations by phone
but the form has not yet arrived:
Beman, Richard Moon, David
Clinger, Will Vandeusen, Mary
Goldstein, Brad Weinreb, Dan
Masinter, Larry White, Jon
If your name is not in one of these lists and you
think it should be, please let me know ASAP.
Thanks,
Ellen
Waldrum%ti-csl@csnet-relay
214-995-6716
P.S. I will have receipts for the checks available
at the meeting.
∂27-Nov-86 1355 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Additional reservations
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 27 Nov 86 13:55:32 PST
Received: from ti-csl by csnet-relay.csnet id bz12469; 27 Nov 86 16:45 EST
Received: from Puff (puff.ARPA) by tilde id AA09163; Wed, 26 Nov 86 15:41:43 cst
To: x3j13@SU-AI.ARPA
Cc: ellen%Puff%ti-csl.csnet@RELAY.CS.NET
Subject: Additional reservations
Date: 26-Nov-86 15:36:49
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2742413804@Puff>
When I send the original list of reservations, a
few names were inadvertently omitted. The following
people have also made phone reservations, but the
paperwork has not yet arrived:
Antonisse, James
Bobrow, Danny
Chaihalloux, Jerome
Giansiracusa, Bob
Mathis, Bob
Ohlander, Ron
Pitman, Kent
Steele, Guy
I have received a reservation form from Mary Van Deusen.
-- Ellen
∂05-Dec-86 1733 MATHIS@ADA20.ISI.EDU meeting in Dallas
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 17:33:15 PST
Date: 5 Dec 1986 11:46-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: meeting in Dallas
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 5-Dec-86 11:46:24.MATHIS>
I have just sent out some last minute documents. I hope that you
have all made your arrangements. Two messages follow: first is
cover letter on that mailing; second is draft agenda outline. If
you have any questions or comments, please be in touch. -- Bob
∂05-Dec-86 1734 MATHIS@ADA20.ISI.EDU Dallas meeting draft agenda outline
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 17:34:02 PST
Date: 5 Dec 1986 12:00-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: Dallas meeting draft agenda outline
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 5-Dec-86 12:00:32.MATHIS>
agenda header -- 1
1 Call to Order, December 10, 1:00pm
2 Opening Remarks and Introductions
3 Approval of Agenda
4 Approval of Minutes of Sept 23-24 Meeting (Doc: 86-???)
5 Report on International Activities (Doc: 86-017)
6 Other Liaison Reports
7 Review of Goals and Objectives (Doc: 86-005)
8 Brief Overview of Technical Topics on Agenda
9 Recess, 5:00pm
agenda header -- 2
10 Call to Order, December 11, 9:00am
11 Function/Value Cells (Doc: 86-010)
12 Relationship of Common Lisp and Scheme
13 European approach to defining via levels
14 LUNCH Second Day, 12:00-1:00pm
15 Error Systems (Doc: 86-011, 86-012, 86-013, 86-014)
16 Update on object system discussions (Doc: 86-018)
17 Handling technical discussions
18 Recess, 5:00pm
agenda header -- 3
19 Call to Order, December 12, 9:00am
20 Summary of Technical Issues and Discussions
21 Planning Relative to Other Technical Issues
22 Call for Officer Candidates
23 Future Meeting Schedule (Doc: SD-04)
24 Review of Action Item Assignments
25 Adjournment, 12:00noon
∂05-Dec-86 1733 MATHIS@ADA20.ISI.EDU third mailing cover letter
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 17:33:25 PST
Date: 5 Dec 1986 11:56-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: third mailing cover letter
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 5-Dec-86 11:56:16.MATHIS>
Doc. No.: X3J13/86-015
Date: December 1, 1986
Project: X3J13 Common Lisp
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
Ph: (703)425-5923
Mathis
X3J13 Members, alternates, observers, and potential participants:
This is a last minute reminder of the next meeting in Dallas on
December 10-12, 1986. If you have yet to make your reservations,
call Beverly at TI at (214)997-2108 or for general information,
Ellen Waldrum at (214)995-6716.
1. The minutes of first meeting have been delayed due to an
unforeseen sequence of unforeseeable circumstances which should
have been predictable. They are promised for the meeting in
Dallas.
2. Enclosed with this letter are the preliminary papers on
function cells and error systems.
3. At the ISO/TC97/SC22 Advisory Group meeting in Vienna, it was
decided to move ahead for a new work item on Lisp with a convenor
coming from France and a project editor coming from the United
States. This will be an item for discussion at the Dallas
meeting.
4. I had the opportunity to meet with Cathie Kachurik of the X3
Secretariat and Gary Robinson of DEC (who also happens to be
quite active in X3 and ISO/TC97) about the use of the Steele book
as a basis for the eventual standard. This issue was the basis
for some motions at the last meeting, which at the current time
are out of order. In our general discussions of goals and
objectives for the X3J13 committee, we need to discuss the actual
form we envision for the eventual standard and how closely it may
be related to the Steele book or to other manuals which have been
developed by other companies.
5. Remember that after this second meeting, we will have to
propose to X3 a set of officer candidates for X3J13. If anybody
wants to serve they should be prepared to make it known at this
meeting.
6. There will be a detailed proposed agenda at the start of the
meeting, but for your planning: Wednesday afternoon will include
brief overviews of the various topics on the agenda and an
extended discussion of goals and objectives for X3J13; Thursday
morning will begin with the function/value cell discussion;
Thursday afternoon will begin with the error system discussion;
and Friday morning will be devoted to finishing up remaining
topics.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
Attachments:
X3J13/86-010 "Issues of Separation in Function Cells and Value
Cells" by Gabriel and Pitman with others
X3J13/86-011 "Exceptional Situations in Lisp" by Pitman
X3J13/86-012 "Error Proposal #8 as of 8/4/86" by Pitman
X3J13/86-013 "Error Proposal #8 implementation suggestion as
of 8/4/86" by Pitman
X3J13/86-014 "Error Proposal Feedback up to 11/19/86"
∂05-Dec-86 1825 FAHLMAN@C.CS.CMU.EDU Logisitcs for Dallas meeting
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 18:25:39 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 5 Dec 86 21:25:36-EST
Date: Fri, 5 Dec 1986 21:25 EST
Message-ID: <FAHLMAN.12260501376.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: x3j13@SU-AI.ARPA
Subject: Logisitcs for Dallas meeting
I have a couple of questions about local arrangements for the Dallas
meeting. Could someone from TI send the following info to this mailing
list. (My apologies if this info was in some earlier mailing -- I can't
seem to find it if so. Maybe it was on the reservation form, which I
mailed in and didn't copy.)
1. Mailing address and phone number of the Sheraton Park Central.
2. How to get there from DFW airport. Approximate price and time
required for a taxi. Is there any cheaper way to make the trip, such as
a hotel limo? A lot of us will probably be arriving 10 - noon on
Wednesday, and will be heading back to the airport after adjornment on
Friday.
Thanks,
Scott
∂08-Dec-86 0902 jjohnson@mitre.ARPA Re: meeting in Dallas
Received: from MITRE.ARPA by SAIL.STANFORD.EDU with TCP; 8 Dec 86 09:00:46 PST
Date: Mon, 8 Dec 86 11:50:17 est
From: jjohnson@mitre.ARPA (Jerry Johnson)
Full-Name: Jerry Johnson
Message-Id: <8612081650.AA17339@mitre.ARPA>
Organization: The MITRE Corp., Washington, D.C.
To: MATHIS@ADA20.ISI.EDU, x3j13@SU-AI.ARPA
Subject: Re: meeting in Dallas
Bob
My new mailing address is
Jerry Johnson
MITRE Corp
Mail Stop W418
1820 Dolley Madison Blvd
McLean VA 22102
Jerry
∂10-Dec-86 0358 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Logistics for Dallas Meeting
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 10 Dec 86 03:57:48 PST
Received: from ti-csl by csnet-relay.csnet id ad02710; 10 Dec 86 6:34 EST
Received: from Puff (puff.ARPA) by tilde id AA00397; Mon, 8 Dec 86 17:37:01 cst
To: x3j13@SU-AI.ARPA
Cc: ellen%Puff%ti-csl.csnet@RELAY.CS.NET
Subject: Logistics for Dallas Meeting
Date: 8-Dec-86 16:50:13
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2743455011@Puff>
Thanks for the suggestion, Scott.
The mailing address of the hotel is
Sheraton Park Central
12720 Merit Drive
Dallas, Texas 75251
and the phone number is 214-385-3000.
Taxi fare from DFW to the hotel should be
approximately $20. There is also a shuttle
service called The Link that charges $9.
The approximate travel time is 30 minutes.
-- Ellen
∂12-Dec-86 1900 MATHIS@ADA20.ISI.EDU Dallas meeting
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 12 Dec 86 18:55:23 PST
Date: 12 Dec 1986 18:25-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: Dallas meeting
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU]12-Dec-86 18:25:14.MATHIS>
Thanks to everyone. I think we had a very productive meeting.
We have a lot of work to do in preparation for the March 16-18,
1987, meeting in Palo Alto. Let's keep the communication going.
Watch this space and help fill it. -- Bob Mathis
∂15-Dec-86 1630 RPG Contents of the X3J13 mailing list
To: x3j13@SAIL.STANFORD.EDU
Here they are:
rpg
#msg.msg[jnk,jmc]
hst
"uwmcsd1!marque!maxiv"@UNIX.MACC.WISC.EDU
coffee@AEROSPACE.ARPA
cugini@ICST-ECF
dabrowski@ICST-ECF
"J.Dalton%uk.ac.edinburgh"@CS.UCL.AC.UK
ffitch@RAND-UNIX
padget@RAND-UNIX
NGALL@BBNG.ARPA
"barmar%bco"@HI-MULTICS.ARPA
hadden@HI-MULTICS.ARPA
hemphill@NRL-AIC.ARPA
"uwmcsd1!marque!gregj"@RSCH.WISC.EDU
"fkunze%franz.uucp"@UCBVAX.Berkeley.EDU
"jkf%franz.uucp"@UCBVAX.Berkeley.EDU
"smh%franz.uucp"@UCBVAX.Berkeley.EDU
Baggins@IBM.COM
Brandon@IBM.COM
"marick%mycroft"@GSWD-VMS.ARPA
dougr@MIT-EDDIE.ARPA
"primerd!barryn"@MIT-EDDIE.ARPA
"mcvax!inria!chaillou"@seismo.CSS.GOV
"mcvax!inria!crcge1!neidl"@seismo.CSS.GOV
peck@SPAM.ISTC.SRI.COM
scherlis@VAX.DARPA.MIL
squires@VAX.DARPA.MIL
gls@ZARATHUSTRA.THINK.COM
Wegman@IBM.COM
antonisse@MITRE.ARPA
jjohnson@MITRE.ARPA
Wieland@MITRE.ARPA
Yonke@USC-ECL.ARPA
Ohlander@ISI.EDU
balzer@A.ISI.EDU
Mathis@A.ISI.EDU
berman@VAXA.ISI.EDU
masinter.pa@Xerox.COM
Adler.pa@XEROX.COM
Bobrow.pa@XEROX.COM
pavel.pa@XEROX.COM
daniels.pa@XEROX.COM
gregor.pa@XEROX.COM
Ricci.pa@XEROX.COM
Sye.pasa@XEROX.COM
vittal.pasa@XEROX.COM
"JerryB%OZ"@XX.LCS.MIT.EDU
Hewitt@XX.LCS.MIT.EDU
"willc%tekchips@tek.csnet"@RELAY.CS.NET
"sridhar%tekchips@tek.csnet"@RELAY.CS.NET
"angela%gmdtub.uucp@Germany.csnet"@RELAY.CS.NET
"Bartley%TI-CSL"@RELAY.CS.NET
"Bate%TI-CSL"@RELAY.CS.NET
"Dussud%AUSOME%TI-CSL"@RELAY.CS.NET
"ida%utokyo-relay.csnet"@RELAY.CS.NET
"Waldrum%TI-CSL"@RELAY.CS.NET
"TURBA%sperry-csd.csnet"@RELAY.CS.NET
bawden@MC.LCS.MIT.EDU
RG@MC.LCS.MIT.EDU
"mike%acorn"@LIVE-OAK.LCS.MIT.EDU
"RSG%OZ"@AI.AI.MIT.EDU
JAR@MC.LCS.MIT.EDU
Soley@MC.LCS.MIT.EDU
"edsel!eb"@NAVAJO.STANFORD.EDU
"edsel!jonl"@NAVAJO.STANFORD.EDU
"edsel!jlz"@NAVAJO.STANFORD.EDU
fahlman@C.CS.CMU.EDU
RAM@C.CS.CMU.EDU
sgadol@Sun.COM
Muchnick@Sun.COM
CPerdue@Sun.COM
"quintus!gehrig!bak"@Sun.COM
Moon@SCRC-STONY-BROOK.ARPA
KMP@SCRC-STONY-BROOK.ARPA
DLW@SCRC-STONY-BROOK.ARPA
Goldstein@SCRC-STONY-BROOK.ARPA
ACW@SCRC-STONY-BROOK.ARPA
chaowatkins@SCRC-STONY-BROOK.ARPA
griss@HPLABS.HP.COM
"DCM%HPFCLP"@HPLABS.HP.COM
chapin@hplabs.hp.com
Krall@MCC.COM
Loeffler@MCC.COM
"Brown%Bach.Dec.Com"@DECWRL.DEC.COM
slater@umbc2.umd.edu
∂19-Dec-86 0608 MATHIS@ADA20.ISI.EDU minutes of Dallas meeting
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 06:07:53 PST
Date: 19 Dec 1986 05:51-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: minutes of Dallas meeting
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]19-Dec-86 05:51:46.MATHIS>
Gary Brown has already sent me the draft minutes of the Dallas
meeting. They seem very good, but he and I are still double
checking each other. If you want to see the preliminary version,
I will forward it to you; if you would rather wait, they will
come in about ten days. -- Bob Mathis
∂19-Dec-86 0608 MATHIS@ADA20.ISI.EDU proposed purposes
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 06:07:38 PST
Date: 19 Dec 1986 05:46-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: proposed purposes
Subject: [Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
sigh, sigh! Guy got this done, but to me on a day I was off the
net. He has inserted some sight additions. We should discuss
this on the net so that we can make a clean copy with clearly
specified alternate wordings so that we could vote on it point by
point at the next meeting. In Dallas I got the feeling that if
we had a clean text, it would probably be passed unanimously.
This is the chance for all of you (particularly those who could
not be in Dallas) to participate in the discussion. -- Bob
Mathis
Begin forwarded message
Received: FROM GODOT.THINK.COM BY USC-ISIF.ARPA WITH TCP ; 16 Dec 86 09:46:39 PST
from boethius by Godot.Think.COM via CHAOS; Tue, 16 Dec 86 12:45:00 EST
Date: Tue, 16 Dec 86 12:46 EST
From: Guy Steele <gls@Think.COM>
To: mathis@ada20.isi.edu
Cc: gls@AQUINAS
Subject: [gls@Think.COM: X3J13 charter (proposed)]
Return-Path: <gls@Think.COM>
Message-ID: <861216124628.6.GLS@BOETHIUS.THINK.COM>
Sigh. I mailed this Friday evening, but to the wrong address.
--Guy
----------------------------------------------------------------
Purposes of X3J13 Committee (Proposed)
1. X3J13 is chartered to produce an American National
Standard for Common Lisp. It will codify existing practice,
provide extensions to facilitate portability of code among
diverse implementations, and establish normative Common Lisp
programming practice.
2. The committee will begin with the language described in
{\it Common Lisp: The Language} by Guy L. Steele Jr. (Digital
Press, 1984), which is the current {\it de facto} standard for
Common Lisp. Whenever there is a proposal for the standard to
differ from {\it Common Lisp: The Language}, the committee
shall weigh both future costs of adopting (or not adopting) a
change and costs of conversion of existing code. Aesthetic
criteria shall be a subordinate consideration.
3. The committee will address at least the following topics
in the course of producing the standard, in each case either
incorporating specific features or explaining why no action
was taken:
(a) Repairing mistakes, ambiguities, and minor ommissions
in {\it Common Lisp: The Language}
(b) Error handling and condition signalling
(c) Semantics of compilation
(d) Object-oriented programming
(e) Iteration constructs
(f) Multiprocessing
(g) Graphics
(h) Windows
(i) Validation
(j) One versus two namespaces for functions and variables
Topics (a)-(c) concern deficiencies in {\it Common Lisp: The
Language} that require resolution. Topics (d) and (e) are not
addressed by {\it Common Lisp: The Language} but appear to be
well-understood and ready for standardization. Topics (f)-(i)
concern areas where standardization is desirable but not
crucial to production of a standard. Topic (j) is an area of
current controversy within the Lisp community. Other topics
may be considered if specific proposals are received.
4. The committee recognizes that Lisp programming practice
will continue to evolve and anticipates the need for future
revisions and extensions to the standard. This may include a
family of Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international
Lisp standard.
[Possible amendment: change the word "extensions" in the first
paragraph to "additional features".]
--------------------
End forwarded message
∂19-Dec-86 0727 FAHLMAN@C.CS.CMU.EDU proposed purposes
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 07:27:45 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 19 Dec 86 10:26:34-EST
Date: Fri, 19 Dec 1986 10:26 EST
Message-ID: <FAHLMAN.12264051413.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MATHIS@ADA20.ISI.EDU
Cc: x3j13@SAIL.STANFORD.EDU
Subject: proposed purposes
In-reply-to: Msg of 19 Dec 1986 08:46-EST from MATHIS at ADA20.ISI.EDU
Looks excellent to me.
The proposed ammendment (extensions -> additional features), seems like
a useful clarification.
-- Scott
∂19-Dec-86 0831 Bobrow.pa@Xerox.COM Re: proposed purposes
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Dec 86 08:31:04 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 DEC 86 08:31:11 PST
Date: 19 Dec 86 08:30 PST
Sender: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: proposed purposes
In-reply-to: MATHIS@ADA20.ISI.EDU's message of 19 Dec 86 05:46 PST
To: MATHIS@ADA20.ISI.EDU
cc: x3j13@SAIL.STANFORD.EDU
Message-ID: <861219-083111-7132@Xerox>
I like this very much -- with the suggested change:
extensions --> additional features
It captures both the need for resolving the current set of issues
relatively quicly for the current community, and also possible futures
that could involve more work, but provide great benefit.
danny
∂19-Dec-86 0936 ohlander@venera.isi.edu Re: proposed purposes
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 09:35:49 PST
Posted-Date: Fri 19 Dec 86 09:35:29-PST
Received: by venera.isi.edu (5.54/5.51)
id AA22770; Fri, 19 Dec 86 09:35:30 PST
Date: Fri 19 Dec 86 09:35:29-PST
From: Ron Ohlander <OHLANDER@venera.isi.edu>
Subject: Re: proposed purposes
To: MATHIS@ada20.isi.edu
Cc: X3J13@sail.stanford.edu
Message-Id: <VAX-MM(195)+TOPSLIB(124) 19-Dec-86 09:35:29.VENERA.ISI.EDU>
In-Reply-To: Message from "MATHIS@ADA20.ISI.EDU" of 19 Dec 1986 05:46-PST
Looks good. I vote for the document with the change of "additional
features" to "extensions".
Ron
-------
∂19-Dec-86 0958 ohlander@venera.isi.edu Re: proposed purposes
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 09:58:18 PST
Posted-Date: Fri 19 Dec 86 09:43:35-PST
Received: by venera.isi.edu (5.54/5.51)
id AA22910; Fri, 19 Dec 86 09:43:36 PST
Date: Fri 19 Dec 86 09:43:35-PST
From: Ron Ohlander <OHLANDER@venera.isi.edu>
Subject: Re: proposed purposes
To: MATHIS@ada20.isi.edu
Cc: X3J13@sail.stanford.edu
Message-Id: <VAX-MM(195)+TOPSLIB(124) 19-Dec-86 09:43:35.VENERA.ISI.EDU>
In-Reply-To: Message from "MATHIS@ADA20.ISI.EDU" of 19 Dec 1986 05:46-PST
Looks good. I vote for the document with the change of "extensions"
to "additional features."
Ron
-------
∂19-Dec-86 1155 berman@vaxa.isi.edu Re: proposed purposes,
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 11:55:25 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA17572; Fri, 19 Dec 86 11:55:23 pst
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8612191955.AA17572@vaxa.isi.edu>
Date: 19 Dec 1986 1155-PST (Friday)
To: MATHIS@ADA20.ISI.EDU
Cc: x3j13@SAIL.STANFORD.EDU
Subject: Re: proposed purposes,
[Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
In-Reply-To: Your message of 19 Dec 1986 05:46-PST.
<[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
Me Like. Ugh.
RB.
∂19-Dec-86 1323 DLW@ALDERAAN.SCRC.Symbolics.COM proposed purposes
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 19 Dec 86 13:19:50 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 32441; Fri 19-Dec-86 15:52:55 EST
Date: Fri, 19 Dec 86 15:54 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: proposed purposes
[Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
To: MATHIS@ADA20.ISI.EDU, x3j13@SAIL.STANFORD.EDU
In-Reply-To: <[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
Message-ID: <861219155422.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
This looks fine. The spelling of "ommissions" should omit one of the
m's. I agree that "extensions" should be changed to "additional
features".
∂19-Dec-86 2017 Moon@RIVERSIDE.SCRC.Symbolics.COM proposed purposes
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 19 Dec 86 20:17:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 87742; Fri 19-Dec-86 23:15:26 EST
Date: Fri, 19 Dec 86 23:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: proposed purposes
[Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
To: MATHIS@ADA20.ISI.EDU
cc: x3j13@SAIL.STANFORD.EDU
In-Reply-To: <[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
Message-ID: <861219231549.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I think this is an excellent charter for X3J13. I approve of the
wording and especially of the attitude about what is important and the
choice to finish Common Lisp rather than embarking on a new experiment.
One comment on "establish normative Common Lisp programming practice":
I doubt it's actually possible to get such a large group of Lisp programmers
to agree in any meaningful way on issues of programming style. If this
goal is achieved, it will be a monumental accomplishment. My preference
would be to leave it to the professors and the authors of textbooks, but
I have no real objection. After all, some of the lettered items will be
fairly difficult to bring to closure too.
∂22-Dec-86 1849 hpfclp!dcm@hplabs.HP.COM Charter statement
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 22 Dec 86 18:49:07 PST
Received: by hplabs.HP.COM ; Mon, 22 Dec 86 14:07:40 pst
From: hpfclp!dcm@hplabs.HP.COM
Received: by hpfclp; Mon, 22 Dec 86 10:24:52 mst
Date: Mon, 22 Dec 86 10:24:52 mst
Return-Path: <hpfclp!dcm>
Received: from hpfcdcm.UUCP; Mon, 22 Dec 86 10:15 MST
To: hpfclp!x3j13@sail.stanford.edu
Subject: Charter statement
This may have already appeared from another source, I'm not sure since there
seems to be some problem with my mail address. Here is the text of Guy's
statement of purpose with some comments from the discussions. Words or
clauses that were topics of discussion are enclosed in []s. Additional notes
are indented after each item.
Dave Matthews
------------------------------------------------------------------------------
Revise draft 86-005
Purposes of X3J13 Committee (proposed)
1. X3J13 is chartered to produce an American National Standard for Common Lisp.
It will codify existing practice, provide [extensions] [necessary] to
[facilitate] portability of code among diverse implementations and [establish]
normative [Common] Lisp programming practice.
change establish to stabilize?
extensions is a loaded word, are they required or not, maybe features is
a better word?
should a stronger term than facilitate be used
are we really establishing a programming practice, including style, etc
2. The committee will begin with the language described in Common Lisp: the
Language by Guy L. Steele Jr., which is the current de facto standard for
Common Lisp. Whenever there is a proposal for the standard to differ from CLTL
the committee shall weigh both future costs of adopting (or not adopting) a
[feature] and costs of conversion of existing code. [Aesthetic criteria shall
be a subordinate consideration.]
feature might be better said as change
should the clause about aesthetics exist at all
3. The committee will address at least the following topics in the course of
producing the standard, in each case either incorporating specific features or
explaining why no action was taken:
a) repairing [errors/mistakes], ambiguities and minor omissions in CLTL
b) error handling/condition signalling
c) semantics of compilation
d) object-oriented programming
e) iteration [the LOOP] constructs
f) multiprocessing
g) graphics
h) windows
i) one or two name spaces for functions or values
j) validation
Topics (a)-(c) concern deficiencies in CLTL that require resolution. Topics
(d) and (e) are not addressed by CLTL but appear to be well-understood and
ready for standardization. Topics (f)-(h) concern areas where standardization
is desirable but not crucial to production of a standard. Topic (i) is an
area of current controversy in the LISP community.
Topic (j) is not currently clarified.
4. The committee recognizes that Lisp programming practice will continue to
evolve, and anticipates the need for future revisions and extensions to the
standard. This may include a family of Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international Lisp standard.
separated from item 4.
∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU 2nd meeting minutes X3J13/86-021
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87 17:27:05 PST
Date: 5 Jan 1987 17:12-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: 2nd meeting minutes X3J13/86-021
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jan-87 17:12:03.MATHIS>
DRAFT Minutes X3J13 Committee Meeting
Dates: December 10, 11, 12, 1986
Location: Sheraton Park Central Hotel, Dallas, Texas
Chair: Bob Mathis (acting)
Secretary: Gary Brown (acting)
Hour of opening: December 10, 1986 1:20 PM
Hour of adjournment: December 12, 1986 11:25 AM
List of Voting members: Attached
Approved Agenda: Attached (86-0016)
Approval of previous minutes: None were prepared
Register of Documents: Attached
Motions seconded and not withdrawn:
Motion to formally thank Ellen Waldrum and Texas Instruments for
the meeting arrangements.
Moved by Dave Slater
Seconded by Peter Coffee
Unanimously approved
Future meeting schedule:
The next meeting is scheduled for March 16, 17 and 18, 1987 in Palo
Alto, California. Dick Gabriel will make the arrangements.
List of action items assigned to committee members:
Working groups were formed for eleven areas requiring investigation
and a convenor was assigned for each group. These groups are
informally charged with bringing evaluation and recommendations back
to the full committee. The body of the minutes lists the groups
and their convenors.
Meeting Summary:
Call to Order:
The meeting was called to order at 1:20 PM.
Opening remarks:
Bob Mathis specified significant dates for X3J13:
December 30, 1986: Wrapup mailing for second meeting
January 9, 1987: Minutes for second meeting due
January 15, 1987: Membership fees due (however no one has
yet received bills)
February 4, 1987: Deadline for next meetings mailing
February 10, 1987: Mailing for meeting 3
Bob Mathis introduced himself discussed his background. All attendees
then introduced themselves.
Approval of agenda:
The agenda, X3J13/86-016, was approved without objection.
Approval of minutes:
The minutes of the first meeting (September 23-24) were not available.
Report on International Activities:
Bob Mathis attended SC22 in Vienna and reported on that meeting.
The major decision was that an ISO Lisp committee would be formed
with a convenor from France and a project editor from the United
States.
Dick Gabriel reported on the "EuLisp" meeting in Paris. The
"EuLisp" group intends to work through ISO and Christian Queinnec
would be group convenor. Several technical issues were also
discussed at the Paris meeting and it is obvious that there
are some technical differences between the initial "EuLisp"
proposal and Common Lisp.
Other liaisons reports:
Bob Mathis asked if there were any volunteers to review:
o Guidelines for programming language conformity and testing
o Programming language standards document standard (i.e. a standard
for how a standard should be written)
Mathis also reported that DEC Press would cooperate with X3J13 in
preparation of standards document. However, initial discussions
with ANSI on allowing the "free" distribution of the standard
document were not encouraging.
Review of Goals and Objectives (86-005):
Approximately an hour and a half was spent discussing the proposed
goal statement for X3J13. Issues raised included:
o the relationship between X3J13 and an ISO Lisp standard effort
o conservative vs ambitious planning and language design
o de-facto vs real standards
Various committee members contributed opinions and historical anecdotes.
No formal motions were made.
Overview of technical topics.
Dick Gabriel gave a brief overview of issues surrounding function
and value cell separation. Kent Pitman gave a overview of the
proposed condition handling system.
Recess:
The meeting was recessed on December 10, 1986 at 5:30 PM.
Call to Order:
The meeting was resumed on December 11, 1986 at 9:07 AM.
Function/Value Cells (86-010):
Dick Gabriel presented the technical issues raised in "Issues of
Separation in Function Cells and Value Cells" (86-010). This topic
was dsicussed for two and a half hours.
Lunch:
The meeting was recessed for lunch from 11:45 AM to 12:50 PM.
Goals and Objectives:
Danny Bobrow presented some alterations to the "Goals and Objectives".
These proposed changes included:
o Stating that X3J13 would work on two fronts; ANS standard for Common
Lisp and working with ISO to prodcue Lisp standard for the longer term.
o Stating we would address other areas such as windows, graphics and
multi-processing
Jerome Chailloux gave his opinions on the goals for X3J13.
Error Systems:
Kent Pitman presented a description of the proposed Common Lisp
Condition handling system. Discussions lasted an hour and fifteen
minutes. Kent believes this proposal is relatively firm and a
final specification will be available soon.
Update on object systems:
Danny Bobrow presented the status of the proposed Common Lisp
object subsystem. The major change between current design and
what was previously proposed is no longer using DEFSTRUCT for
object definition but instead using two new macros; DEFRECORD and
DEFCLASS. Danny believes that this work is progressing well and
expects convergence before the next meeting.
Goal and Objectives:
Approximately half an hour was spent in another open discussion
X3J13 of Goals and Objectives. Bob Mathis suggested that an
ANS standard separate from ISO might be rejected by X3.
Recess:
The meeting was recessed on December 11, 1986 at 5:15 PM.
Call to Order:
The meeting was resumed on December 12, 1986 at 9:10 AM.
The committee voted to formally thank Ellen Waldrum and Texas
Instruments for the meeting arrangements.
Handling Technical Issues:
Bill Scherlis reported on the reccommendations of a subgroup formed
to discuss effective ways for X3J13 to discuss and decide issues.
They suggested that small working groups be formed to:
o Prepare briefings for the entire committee
o Evaluate the costs and benefits of alternative
o Make recommendations for appropriate action.
The following task groups were suggested. The person speicified is
the acting chair for each group [other initial members are listed].
1. Steele book cleanup Scott Fahlman
[Matthews, Pitman, White, Maisinter, Steele]
2. Lisp1/Lisp2 Dick Gabriel
[Pitman, Clinger, Wegman, Giansiracusa, Weinreb]
3. Objects Danny Bobrow
[Gabriel, Moon, Dusaud, Gregor, Keen, DeMicale]
4. Errors and conditions Kent Pitman
[Daniels]
5. Validation and conformance Rich Berman
[Beckerle, Slater, White]
6. Types and declarations Bill Scherlis
[Curtis, Slater, Poser]
7. Macros Kent Pitman
[Haflich, Wegman]
8. Compiler specification Steve Haflich
[Beckerle, Bartly, MacLaughlin]
9. Presentation of standard Gary Brown
[Matthews, Lieberman, Ohlander, Rosenking, Boelk, Ennis]
10. Graphics and windows Doug Rand
[Masinter, Hadden, Waldrum, Debrowski]
11. Iteration JonL White
[Weinreb, Perdue]
Groups to discuss multiprocessing, transition management and ISO
iteraction were proposed but not formed.
Goal and Objectives:
Guy Steele presented the recommendation of a subgroup formed
to create another draft of the Goals and Objectives statement for
X3J13. Here is a draft of this document:
1. X3J13 is chartered to produce an American National Standard
for Common Lisp. It will codify existing practice, provide
features to facilitate portability of code among diverse
implementations and establish normative Common Lisp practice.
2. The committee will begin with the language described in "Common
Lisp: the Language" by Guy L. Steele Jr., which is the current
"de facto" standard for Common Lisp. Whenever there is a
proposal for the Standard to differ from CLtL, the committee
shall weigh both future costs of adopting (or not adopting)
a change and costs of conversion of existing code. Aesthetic
criteria shall be a subordinate consideration.
3. The committee will address at least the following topics
in the course of producing the standard, in each case either
incorporating specific features or explaining why no action
was taken:
(a) Repairing mistakes, ambiguities and minor omissions in CLtL
(b) Error handling/condition signalling
(c) Semantics of compilation
(d) Object-oriented programming
(e) Iteration construct(s)
(f) Multiprocessing
(g) Graphics
(h) Windows
(i) One or two namespaces for functions and values
(j) Validation
Topics (a)-(c) concern deficiencies in CLtL that require resolution.
Topics (d) and (e) are not addressed by CLtL but appear to be
well understood and ready for standarization. Topics (f)-(h)
concern areas where standarization is desirable but not crucial
to production of a standard. Topic (i) is an area of current
controversy within the Lisp community. Other topics may be
considered if specific proposals are received.
4. The comittee recognizes that Lisp programming practice will
continue to evolve and anticipates the need for future revisions
and extensions to the standard. This may include a family of
Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international
Lisp standard.
A discussion of this proposal took place followed by an informal
"sense of the committee" vote. The committee overwhelmingly
accepted this proposal. A final draft of this will be prepared
for a formal vote at the next meeting.
Call for officer candidates:
The following committee members are standing for X3J13 elected offices:
o Chair - Bob Mathis
o Vice-chair - Guy Steele
o International Representative - Dick Gabriel
Future meeting Schedule:
The next meeting will be March 16-18, 1987 in Palo Alto, California.
Adjournment:
The meeting was adjourned on December 12, 1986 at 11:25 AM.
Respectfully Submitted,
Gary L. Brown
∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU proposed purposes X3J13/86-020
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87 17:27:30 PST
Date: 5 Jan 1987 17:15-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: proposed purposes X3J13/86-020
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jan-87 17:15:45.MATHIS>
Purposes of X3J13 Committee (Proposed)
1. X3J13 is chartered to produce an American National Standard
for Common Lisp. It will codify existing practice, provide
extensions [amendment: change the word "extensions" to
"additional features".] to facilitate portability of code among
diverse implementations, and establish normative Common Lisp
programming practice.
2. The committee will begin with the language described in Common
Lisp: The Language by Guy L. Steele Jr. (Digital Press, 1984),
which is the current de facto standard for Common Lisp. Whenever
there is a proposal for the standard to differ from Common Lisp:
The Language, the committee shall weigh both future costs of
adopting (or not adopting) a change and costs of conversion of
existing code. Aesthetic criteria shall be a subordinate
consideration.
3. The committee will address at least the following topics in
the course of producing the standard, in each case either
incorporating specific features or explaining why no action was
taken:
(a) Repairing mistakes, ambiguities, and minor ommissions
in Common Lisp: The Language
(b) Error handling and condition signalling
(c) Semantics of compilation
(d) Object-oriented programming
(e) Iteration constructs
(f) Multiprocessing
(g) Graphics
(h) Windows
(i) Validation
(j) One versus two namespaces for functions and variables
Topics (a)-(c) concern deficiencies in Common Lisp: The Language
that require resolution. Topics (d) and (e) are not addressed by
Common Lisp: The Language, but appear to be well-understood and
ready for standardization. Topics (f)-(i) concern areas where
standardization is desirable but not crucial to production of a
standard. Topic (j) is an area of current controversy within the
Lisp community. Other topics may be considered if specific
proposals are received.
4. The committee recognizes that Lisp programming practice will
continue to evolve and anticipates the need for future revisions
and extensions to the standard. This may include a family of
Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international
Lisp standard.
∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU general letter X3J13/86-022
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87 17:26:57 PST
Date: 5 Jan 1987 17:03-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: general letter X3J13/86-022
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jan-87 17:03:23.MATHIS>
Doc. No.: X3J13/86-022
Date: 86-12-30
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
To everyone on the X3J13 (Common Lisp) mailing list:
This letter is being sent out in three different configurations: by
electronic mail to <x3j13> at SAIL (to everyone on that list), by regular
mail with enclosures (to everyone who has given an indication of
participation), and by regular mail without enclosures (to those on the
mailing list who have never responded). People who receive this letter
without enclosures, need to respond to this letter to remain on the mailing
list. Membership on X3J13 is open, but is based on a commitment to
continuing participation.
The Draft minutes of the Dallas meeting are enclosed (Doc: X3J13/86-021).
Thanks to Gary Brown. Included there is the list of initial members in the
task groups we formed (this was also the content of a separate electronic
message). Groups to discuss multiprocessing, transition management and ISO
iteraction were proposed but not formed. At least part of the reason for
not forming the ISO interaction group was that the US delegation to the ISO
working group has not been chosen. Anyone from X3J13 is eligible if they
can make the additional commitment to work, time and travel. If anyone is
interested (no commitment yet) in serving on the ISO delegation, please
contact me; Mathis, Gabriel, and Clinger have already expressed their
interest.
The acting chairs are to make sure that the members of their group
communicate with each other. If it is appropriate that a group set itself
an agenda and select a leader, the acting chair should make sure it
happens. Each of these groups will be called on for a BRIEF report at the
next meeting. If that report will be any more than just an affirmation of
existence, please contact me for scheduling.
As a separate document (Doc: X3J13/86-020) the draft proposed purposes are
also enclosed. This differs slightly from the version in the minutes; it is
X3J13/86-020 (or its revision) that we will be considering at the next
meeting. This has also been circulated electronically.
You (that is people who received enclosures with this letter or who respond
to this letter) will be sent the other documents resluting from the Dallas
meeting separately.
If you have any comments or other documents you want circulated before the
next meeting, please send them to me by February 4, 1987.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
∂06-Jan-87 0723 MATHIS@ADA20.ISI.EDU task groups
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 07:19:23 PST
Date: 6 Jan 1987 07:13-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: task groups
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 6-Jan-87 07:13:41.MATHIS>
This has been covered in my over messages, but
is also being sent separately for emphasis.
-- Bob
At the meeting in Dallas, we decided to form some subgroups
(working groups, task groups, committees, or whatever name). What
follows is a section from the draft minutes giving the initial
structure of these groups. (Thanks to Gary Brown for getting the
minutes ready so promptly.) Others are free to join these groups,
but the size of each group should remain reasonable and
individuals should recognize they are making a commitment by
joining.
Bill Scherlis reported on the recommendations of a subgroup
formed to discuss effective ways for X3J13 to discuss and decide
issues. They suggested that small working groups be formed to:
o Prepare briefings for the entire committee
o Evaluate the costs and benefits of alternative
o Make recommendations for appropriate action.
The following task groups were suggested. The person specified is
the acting chair for each group [other initial members are
listed].
1. Steele book cleanup Scott Fahlman
[Matthews, Pitman, White, Maisinter, Steele]
2. Lisp1/Lisp2 Dick Gabriel
[Pitman, Clinger, Wegman, Giansiracusa, Weinreb]
3. Objects Danny Bobrow
[Gabriel, Moon, Dusaud, Gregor, Keen, DeMicale]
4. Errors and conditions Kent Pitman
[Daniels]
5. Validation and conformance Rich Berman
[Beckerle, Slater, White]
6. Types and declarations Bill Scherlis
[Curtis, Slater, Poser]
7. Macros Kent Pitman
[Haflich, Wegman]
8. Compiler specification Steve Haflich
[Beckerle, Bartly, MacLaughlin]
9. Presentation of standard Gary Brown
[Matthews, Lieberman, Ohlander, Rosenking, Boelk,
Ennis]
10. Graphics and windows Doug Rand
[Masinter, Hadden, Waldrum, Debrowski]
11. Iteration JonL White
[Weinreb, Perdue]
Groups to discuss multiprocessing, transition management and ISO
iteraction were proposed but not formed.
[At least part of the reason for not forming the ISO interaction
group was that the US delegation to the ISO working group has not
been chosen. Anyone from X3J13 is eligible if they can make the
additional commitment to work, time and travel. If anyone is
interested (no commitment yet) in serving on the ISO delegation,
please contact me; Mathis, Gabriel, and Clinger have already
expressed their interest.]
[The acting chairs are to make sure that the members of their
group communicate with each other. If it is appropriate that a
group set itself an agenda and select a leader, the acting chair
should make sure it happens. Each of these groups will be called
on for a BRIEF report at the next meeting. If that report will be
any more than just an affirmation of existence, please contact me
for scheduling.]
∂06-Jan-87 2157 edsel!bhopal!jonl@navajo.stanford.edu proposed purposes
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 21:56:12 PST
Received: by navajo.stanford.edu; Tue, 6 Jan 87 21:55:27 PST
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA01003; Tue, 6 Jan 87 21:48:53 pst
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
id AA16556; Tue, 6 Jan 87 21:46:18 PST
Date: Tue, 6 Jan 87 21:46:18 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8701070546.AA16556@bhopal.edsel.uucp>
To: navajo!MATHIS%ADA20.ISI.EDU@navajo.stanford.edu
Cc: navajo!x3j13%SAIL.STANFORD.EDU@navajo.stanford.edu
In-Reply-To: navajo!MATHIS@ADA20.ISI.EDU's message of 19 Dec 1986 05:46-PST
Subject: proposed purposes
[Sorry for the late entry of this comment -- I sent it out over two weeks
ago, and it got "bounced back" from some mail gateway at Stanford after
a few days of mailer problems; also, I've been "out of action" for
the past two weeks.]
Return-Path: <jonl>
Date: Fri, 19 Dec 86 11:27:59 PST
From: jonl (Jon L White)
To: navajo!MATHIS%ADA20.ISI.EDU
Cc: navajo!x3j13%SAIL.STANFORD.EDU
In-Reply-To: navajo!MATHIS@ADA20.ISI.EDU's message of 19 Dec 1986 05:46-PST
Subject: proposed purposes
At Dallas, there was question about the first paragraph wording:
". . . establish normative Common Lisp programming practice."
Just what does that mean? and how can a committee "establish" it?
Someone suggested that that phrase was a replacement for some nebulous
statement about "portability of programmers", or "portability of skills".
If that is indeed the goal, then it's hard to see how a committee can
"establish" it -- I remember a suggestion being offered to re-word the
whole sentence roughly as follows:
"It will codify existing practice, provide additional features to
enable the portability of code among diverse implementations,
and facilitate the establishment of normative Common Lisp
programming practice."
-- JonL --
∂15-Jan-87 1329 Mailer@XX.LCS.MIT.EDU Document 86-019
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Jan 87 13:29:03 PST
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Jan 87 16:28-EST
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 24905; 15 Jan 87 16:14:20-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 51643; Thu 15-Jan-87 14:31:21-EST
Date: Thu, 15 Jan 87 14:31 est
Sender: mike@acorn
To: x3j13@sail.stanford.edu
From: mike%acorn@mit-live-oak.arpa
Subject: Document 86-019
Note: You will be receiving hardcopy of the following from Bob Mathis.
----------------------------------------------------------------------
!
To: ANSI x3j13
From: Mike Beckerle, Gold Hill Computers
Date: 1/13/87
Subject: Document x3j13/86-019
Since my draft proposal which was hastily drawn up at the last x3j13
meeting, I have had time to reconsider several points in my proposal
for adding a few features to CL to support Higher-Order Functional
Programming. I have also decided to bring up the meta issue in this
forum.
The meta-issue is this: Would adding enough syntactic accommodation
to Common Lisp to make functional programming palatable defuse this
Lisp1 vs. Lisp2 debate enough? Or more optimistically, what level of
accommodation for programming with functionals would in fact defuse
this issue. For example, Would it be enough to provide the following:
Programs written in in a Lisp1 "educational/functional" dialect would
not be directly upwardly compatible with ANS Common Lisp; however,
the changes required would be straightforward to make and
syntactically convenient. (We know that they can't be automatic due
to use of EVAL.) I am particularly trying to address the issues of
Appendix B, section 6 of the "Issues..." paper.
What I'm trying to get at here is this: Why do people want a
"one-cell" lisp? Is it because it promotes/allows effective
programming using higher-order functions (style), because it is
more consistent/cleaner and therefore easier to understand and
teach (conceptual economy), because they are more familiar with a
one-cell lisp than a two cell lisp (momentum), because of a
purely aesthetic view that one cell is "better" (aesthetics),
because they don't like the name-capture problems of
common-lisp's so called "non-hygienic" macros (macrophobia), or
finally because they want political clout (politics).
My approach addresses that the push for lisp1 is due at least
partially to aesthetics but primarily is due to the style issue.
The following is a proposal for adding a small number of features
to Common Lisp to accommodate programming using higher-order
functions, or functionals. Functional programming is much easier
in a Lisp1 dialect than a Lisp2 dialect since functional
programming makes extensive use of functions as values. Common
Lisp's current (Funcall ...) and (Function ...) or #' syntax
makes functional programming particularly awkward. In addition
the fact that one cannot write an application which produces a
function in the car of a list representing an application is a
pain. [let's call this the "((f g) h)" problem.] These features
are intended to accommodate the functional style, without changing
the language too radically from the current status defined in
CLtL.
---------------------------------------------------------------------
!
Document x3j13/86-019
Accommodating Functional-Style Programming in Common Lisp.
Mike Beckerle
Gold Hill Computers
Jan. 6, 1986.
One of the primary motivations for use of Lisp1 dialects is the
ease of higher-order programming. Many of the examples of
effective programming practice in Lisp1 given in the "Issues of
Separation in Function and Value Cells" paper recently discussed
by x3j13 at the Dec. '86 meeting are exactly of this type.
Unfortunately, macro programming in Lisp1 dialects is not well
understood and is a subject of current research; nevertheless
macro programming is heavily entrenched in the Common lisp world.
As a result, the approach advocated in this proposal is to
provide some standard operators and macros which make programming
using higher-order functions in Common Lisp significantly easier.
The Changes to CL as defined in CLtL are enumerated here, after
which there are some examples.
Change 1:
To section 5.2. Functions
Function call forms should be changed to allow the lisp1 like
syntax of:
((f g) h)
((lambda (x) x) #'(lambda (y) y)) 10) => 10.
i.e., the "function" position of an application should be treated
specially only if it contains a SYMBOL. If it contains a list
beginning with something other than LAMBDA it should be
interpreted as an application itself.
The forms above should, in every sense of the word except syntax,
be equivalent to:
(funcall (f g) h)
and
(funcall ((lambda (x) x) #'(lambda (y) y)) 10))
in the current CL as per CLtL.
Essentially, whenever symbols are used as functions, their
function-cell definitions are used. Lambda expressions and
function applications can also be used as functions. Lambda
expressions evaluate to functions. Function applications must
evaluate to either functions or symbols. If they evaluate to
symbols, then (recursively) the function definition of that
symbol is used.
The CL spec can explain the purpose of this special treatment for
function-positioned symbols in terms of the name-capture problem
of macros. Inadvertant name capture is, after all, the only real
reason for the special distinction for funtion-positioned symbols.
!
Change 2: Section 7.1.1.
The FUNCTION special form will be optional in front of
lambda expressions regardless of where they appear in a
program text. (The obvious exception for within quoted lists
obviously applies here, but isn't worth mention.)
It is as if the following definition was part of the CL system
(Defmacro lambda (&rest forms)
`(function (lambda ,@forms)))
The FUNCTION special form is needed only to distinguish between
the function and value of symbols which are either globally
referenced or locally bound using one of FLET, LABELS, MACROLET,
parameter passing, LET, LET*, and MULTIPLE-VALUE-BIND.
!
Change 3: Section 20.2
For syntactic convenience, the value cell of all CL symbols
which are defined as functions are defined to contain
the function object as well as the function cell.
E.g.,
(symbol-value 'mapcar) => #<compiled-function 1234>
(symbol-function 'mapcar) => #<compiled-function 1234>
This allows use of the CL symbols which name CL functions in
variable position without need for the FUNCTION special form as
in (mapcar list '(a b c) '(d e f)). If the value of the variable
"list" is locally bound to a function, possibly using let, then
the local definition will be used in accordance with the rules of
lexical scoping.
The primary change this requires is the renaming of certain
symbols of significance to the standard read-eval-print loop.
I suggest that the following renamings be used:
+ => +1
++ => +2
+++ => +3
- => -- or _ ;; this one's difficult to get a nice name for!
* => *1
** => *2
*** => *3
/ => /1
// => /2
/// =? /3
The behavior of these variables would be identical to the current
behavior of the old-named variables. I consider this change to
be simply cosmetic, aesthetic, etc. No program of any quality
(other than those written as read-eval-print loops by
implementors) ever uses these variables. (Unfortunately, the
Peter Principle dictates that the least significant point always
gets the most debate, so I'm prepared for absolute tirades on
this one! Please restrain yourselves!!!!!)
!
Change 4: Section 7.11. Use of Higher-order Functions
Organizationally, this seems to belong in the chapter 7
discussion, so I've proposed a new section for that chapter
in lieu of any guidelines for how to present standards proposals.
The text as a preliminary draft follows:
"Common Lisp provides some support for programming using higher-
order functions. These allow the programmer to partially hide the
distinction between function-cells and value-cells and to program
as if using a language where only one cell is associated with
each symbol. The objective is to make the syntax of higher-order
programs easier to read and understand. The abstraction that this
creates is not complete; it is possible for programs to detect
that there are separate function and value cells even when these
abstractions are used; however, the syntactic convenience of
using these forms where they are applicable is significant.
FUNCTIONAL Vars* {form}* [Macro]
The Functional macro is used to create an environment where the
variables in the list "Vars" can be used both as variables and
in function position within the body forms without need for the #' or
(function ...) operator, nor use of (funcall ...).
For example:
(defun doublemap (f g)
(functional (f g)
(lambda (list) (f (g (mapcar f list)
(mapcar g list))))))
(defun y (f) ;; the paradoxical combinator
(functional (f)
((lambda (x)
(functional (x)
(f (x x))))
(lambda (x)
(functional (x)
(f (x x)))))))
Here, notice that "f" and "g" are used both as variables
representing functions, and also as functions, as if defined by
FLET or LABELS.
One possible definition for FUNCTIONAL is:
(defmacro functional (vars &body body)
(let* ((bindings (mapcar #'(lambda (name)
`(,name (&rest args) (apply ,name args)))
vars)))
`(flet ,bindings
,@body)))
Implementation note: FUNCTIONAL can also be implemented
using MACROLET.
Care is required if FUNCTIONAL is used in programs which perform
side-effects on symbols via SYMBOL-FUNCTION or SYMBOL-VALUE. The
behavior of the resulting program can be difficult to predict."
!
Change 5: Section 7.1.1. (again)
Note: The following is the least kosher aspect of this proposal,
but I am including it anyway. Once again it is written as an
addition to section 7.1.1. Its intended use is for defining new
named functions which will be associated with both function and
value cells of symbols, thereby forming a consistent extention.
In general, use of side-effects within higher-order programs is
extremely tricky; one tends to program in a pure style out of
necessity.
SYMBOL-CONTENTS symbol [Function]
In order to facilitate programming in the functional style it is
often useful to ignore the function-cell/value-cell aspect of
symbols. Symbol-contents, if used consistently throughout an
entire program can facilitate this style of programming.
The function Symbol-contents can be used to extract or replace the
value of a symbol in a manner which is indifferent to the
normal CL distinction between function cells and value cells.
Symbol-contents returns the contents of the value-cell of the
symbol when used as an accessor. When used as an assigner
(with setf); however, the value assigned is placed into both
the function-cell, and the value-cell.
Symbol-contents cannot access nor assign (using setf) the value
of local symbol or function definitions created using let, flet, labels,
let*, etc. Only the global value can be accessed or modified.
It is an error to execute code which calls a function named by a symbol
where that symbol has been assigned a value other than a function object
via setf of symbol-contents.
(defun foobar (x) x)
(symbol-contents 'x) => #<unbound>
(setf (symbol-contents 'x) (lambda (x) (+ x x)))
(symbol-contents 'x) => #<function-object (lambda (x) (+ x x))>
(symbol-function 'x) => #<function-object (lambda (x) (+ x x))>
(symbol-value 'x) => #<function-object (lambda (x) (+ x x))>
(eq (symbol-function 'x) (symbol-value 'x)) => T
--------------------------------------------------------------------
!
Use of the Higher-order function extensions to CL.
To show the utility of these abstractions in higher order
programming, it is important to look at some example programs.
Hence, I have rewritten the examples in Appendix B of
the "Issues of Separation in Function Cells and Value Cells"
using Common Lisp with the proposed extensions.
;;;---------------------------------------------------------------------
;;; from Appendix B: "High-Order Procedures for Functional Abstractions"
;; our macro for making functional programming easier.
(defmacro functional (vars &body body)
(let* ((bindings (mapcar (lambda (name)
`(,name (&rest args) (apply ,name args)))
vars)))
`(flet ,bindings
,@body)))
;; a macro which obviates #' notation.
(defmacro lambda (&rest forms)
`(function (lambda ,@forms)))
;; the symbol-contents function and its setf.
(defun symbol-contents (name)
(symbol-value name))
(defun set-symbol-contents (name value)
(setf (symbol-value name) value)
(setf (symbol-function name) value))
(defsetf symbol-contents set-symbol-contents)
;; a DEFINE macro, syntactic sugar to make the examples
;; more scheme-like. Doesn't put implicit blocks on lambda's,
;; doesn't handle local defines. This could be done, but we won't bother
;; here.
(defmacro define (name value)
`(setf (symbol-contents ',name) value))
;; misc.
(defun null? (x) (null x))
(defun future (x) x)
(defun assq (x y)
(assoc x y :test 'eq))
;;--------------------------------------------------------------------
!
;; The example programs.
;; these have been translated slightly from Scheme to Common Lisp
;; plus my suggested extentions.
(define sum
(lambda (f a next b)
(functional (f next)
(if (> a b)
0
(+ (f a)
(sum f (next a) next b))))))
(define integral
(lambda (f a b dx)
(functional (f)
(* (sum f (+ a (/ dx 2)) (lambda (x) (+ x dx)) b)
dx))))
(define map
(lambda (f x)
(functional (f)
(if (null x)
nil
(cons (f (car x))
(map f (cdr x)))))))
(define reduce
(lambda (f l)
(functional (f)
(if (null? (cdr l))
(car l)
(f (car l)
(reduce f (cdr l)))))))
(define pairs
(lambda (x k)
(functional (k)
(if (or (null? x) (null? (cdr x)))
(k nil x)
(pairs (cddr x)
(lambda (p r)
(k (cons (list (car x) (cadr x))
p)
r)))))))
(define reduce
(lambda (f x)
(functional (f)
(pairs x
(lambda (p r)
(if (null? p)
(car r)
(reduce f
(append (map (lambda (z)
(future (apply f z)))
p)
r))))))))
(defstruct (table-abstraction
(:constructor make-table-abstraction
(maker looker-up inserter))
(:conc-name nil))
maker looker-up inserter)
(defun hashfunction (n)
(lambda (x)
(mod (sxhash x) n)))
(define hashify
(lambda (n table-abstraction)
(let ((hash (hashfunction n))
(bucket-make (maker table-abstraction))
(bucket-lookup (looker-up table-abstraction))
(bucket-insert! (inserter table-abstraction)))
(functional (hash bucket-make bucket-lookup bucket-insert!)
(let ((make
(lambda ()
(let ((hashtable (make-array n)))
(dotimes (i n)
(setf (aref hashtable i)
(bucket-make)))
hashtable)))
(lookup
(lambda (key table)
(bucket-lookup key
(aref table
(hash key)))))
(insert!
(lambda (key table value)
(bucket-insert! key
(aref table (hash key))
value))))
(make-table-abstraction make lookup insert!))))))
(defun make-entry (key value) (cons key value))
(defun set-value! (vcell value) (rplacd vcell value))
(define alist-table-abstraction
(make-table-abstraction
(lambda () (list '*alist-table*))
(lambda (key table)
(cdr (assq key (cdr table)))) ;; alist of cons pairs
(lambda (key table value)
(let ((vcell (assq key (cdr table))))
(if vcell
(set-value! vcell value)
(rplacd table
(cons (make-entry key value)
(cdr table))))))))
(define hash-table-of-alists-abstraction-generator
(lambda (n) (hashify n alist-table-abstraction)))
(define hash-table-of-alists
(hash-table-of-alists-abstraction-generator 16))
(define two-level-hash-table-abstraction-generator
(lambda (m n table-abstraction)
(hashify m (hashify n table-abstraction))))
(define two-level-hash-table-of-alists-abstraction-1
(two-level-hash-table-abstraction-generator
128 256 alist-table-abstraction))
;;-----------------------------------------------------------------
My observation is that using the FUNCTIONAL abstraction along with the
ability to perform applications which syntactically look like "((f g) h)"
makes the enhanced CL version pretty close to the Lisp1 version at least
as far as syntactic aesthetics are concerned.
∂15-Jan-87 2015 Moon@STONY-BROOK.SCRC.Symbolics.COM Document 86-019
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Jan 87 20:15:31 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 44898; Thu 15-Jan-87 23:13:42 EST
Date: Thu, 15 Jan 87 23:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Document 86-019
To: mike%acorn@MIT-LIVE-OAK.ARPA
cc: x3j13@sail.stanford.edu
In-Reply-To: The message of 15 Jan 87 14:31 EST from mike%acorn@mit-live-oak.arpa
Message-ID: <870115231337.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 15 Jan 87 14:31 est
From: mike%acorn@mit-live-oak.arpa
I don't know if X3J13 is the right mailing list for technical discussions,
but I'd like to offer a few comments on your proposal. To avoid contributing
to total mail overload, I will abbreviate your proposal as much as possible
when referring to it.
Change 1: Function call forms should be changed to allow the lisp1 like
syntax of: ((f g) h)
i.e., the "function" position of an application should be treated
specially only if it contains a SYMBOL. If it contains a list
it should be interpreted as an application itself.
I think this is a good idea. It's a kludge, of course, and creates a
small inconsistency in the language (allowing list forms but not symbol
forms), however I think the ratio of benefit to harm is favorable.
Maclisp on the pdp-10 used to have a feature similar to this, but it was
removed because it caused a lot of problems. I believe the problems can
be traced to the fact that it allowed the result of evaluating a list or
efunctuating a symbol to be another list, which was then evaluated. The
question is, in what lexical scope should that list be evaluated. Your
proposal avoids this problem by forbidding repeated evaluation.
Your proposal allows repeated efunctuation (that is, the result of
evaluating a list can be a symbol, which is then efunctuated) and you
don't specify in what lexical environment the symbol is to be
efunctuated. CLtL is not very clear on this point; p.107 says that
APPLY efunctuates in the global lexical environment if given a symbol,
but otherwise the issue is not addressed as far as I can see. This
feature may not be essential to your proposal; you might want to remove
it.
(For those who haven't seen the term before, "efunctuate" is what the
FUNCTION special form does.)
Change 2: It is as if the following definition was part of the CL system
(defmacro lambda (&rest forms)
`(function (lambda ,@forms)))
This is definitely a good idea and causes no problems.
Change 3:
For syntactic convenience, the value cell of all CL symbols
which are defined as functions are defined to contain
the function object as well as the function cell.
I don't think this is a good idea, because it creates an artificial
distinction between built-in CL functions and functions defined by
the user with DEFUN or LABELS. If the rule of storing the definition
in both cells applies to the latter type of functions too, then
we would just have Lisp1.
Change 4:
The Functional macro is used to create an environment where the
variables in the list "Vars" can be used both as variables and
in function position within the body forms without need for the #' or
(function ...) operator, nor use of (funcall ...).
This is a good idea. To me it seems that having this eliminates the
need for your change 3.
Change 5:
Symbol-contents returns the contents of the value-cell of the
symbol when used as an accessor. When used as an assigner
(with setf); however, the value assigned is placed into both
the function-cell, and the value-cell.
This stands or falls with change 3. Again, I think change 4 is
a better approach.
∂16-Jan-87 0822 FAHLMAN@C.CS.CMU.EDU Document 86-019
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Jan 87 08:21:50 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 16 Jan 87 11:21:29-EST
Date: Fri, 16 Jan 1987 11:21 EST
Message-ID: <FAHLMAN.12271401438.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU, x3j13@SAIL.STANFORD.EDU
Subject: Document 86-019
In-reply-to: Msg of 15 Jan 1987 23:13-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
This discussion should probably be on the Common-Lisp mailing list, but
since I'm responding to Moon's mail to this list, I'll do it here.
I agree totally with Moon on this one -- I was just about to write a
reply with essentially the same content as his, supporting the idea
except for parts 3 and 5.
If the goal is to make functional-style programming easier without
disrupting Common Lisp too badly, I think your proposals (minus numbers
3 and 5) do the job about 90% as well as a move to Lisp1. For those
people whose goal is to merge Common Lisp with Scheme and/or Eulisp,
then only a move to Lisp1 will do. However, unless great progress is
made on the macro issue and on ways of making the conversion less
painful, I think that a move to Lisp1 is unlikely; less radical
proposals such as yours are definitely worth considering.
I like this much better than the &function idea, by the way. that
seems very confusing and irregular to me.
-- Scott
∂16-Jan-87 1124 Masinter.pa@Xerox.COM Re: Document 86-019, &function, etc.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jan 87 11:24:34 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JAN 87 11:24:00 PST
Date: 16 Jan 87 11:24 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Document 86-019, &function, etc.
In-reply-to: various
To: x3j13@sail.stanford.edu
Message-ID: <870116-112400-2364@Xerox>
These proposals fail to meet what I believe is the primary goal of those
who want 1-lisp over 2-lisp, namely, to simplify and make more
consistent the programming language semantics, to reduce the number of
different kinds of references in the language.
Instead, they do the opposite. While superficially bearing some
resemblance to 1-lisp, there are more rules for evaluation rather than
fewer, the description of the language and its semantics is complex,
there are odd exceptions. (For example, in the
funcall-if-car-of-form-is-list proposal, what if the car of the form is
a macro? A macro that expands to a symbol? To a lambda?).
It does no good to pick some minor syntactic feature of 1-lisp,
implement that, and ignore the basic principle.
∂16-Jan-87 2155 willc%tekchips.tek.com@RELAY.CS.NET Re: Document 86-019
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 16 Jan 87 21:55:29 PST
Received: from tektronix.tek.com by csnet-relay.csnet id ab04827;
17 Jan 87 0:43 EST
Received: by tektronix.TEK.COM (5.31/6.18)
id AA04079; Fri, 16 Jan 87 21:25:51 PST
Received: by tekchips.TEK (5.31/6.16)
id AA12223; Fri, 16 Jan 87 14:56:26 PST
Message-Id: <8701162256.AA12223@tekchips.TEK>
To: x3j13@SU-AI.ARPA
Cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU
Subject: Re: Document 86-019
In-Reply-To: Your message of Thu, 15 Jan 87 14:31 est.
<8701160757.AA02526@tekchips.TEK>
Date: 16 Jan 87 14:56:21 PST (Fri)
From: willc%tekchips.tek.com@RELAY.CS.NET
Mike Beckerle asked some interesting questions and suggested some possible
answers. Ultimately, he is asking for a philosophy of programming language
design. Here's mine.
* * *
Programming is hard because it's hard to know what you want the machine
to accomplish (the problem), and it's hard to know how to accomplish it
(the algorithm). If you knew these two things, it ought to be easy to
program the machine to do what you want.
It usually isn't. The reason is that you have to learn all sorts of arcane
things about the computing environment and programming language that you
use. These details have nothing to do with the problem you're trying
to solve. Even so, they may be almost as difficult to master.
Most people, being reasonable, don't try to master their programming
language completely, particularly if their programming language is big
and complicated. In my experience, the main thing that a programming
language can do for these people is to be consistent with a simple mental
model that they can use without getting into trouble. Extra features
that help people get their work done more easily are nice, but it is more
important that the language not get in their way. It is most important
that the language not be full of nasty surprises for its users.
This principle of programming language design is sometimes known as the
"Law of Least Astonishment", in waggish recognition of the fact that even
the best design efforts are ad hoc in part. Its motivation is very
pragmatic, its application very practical. It says that simplicity,
elegance, and aesthetics pay off.
* * *
In answer to some of Mike's specific questions, people prefer a single-
environment Lisp because of style, conceptual economy, and aesthetics; I
see little difference between conceptual economy and aesthetics, which is
perhaps a clue to my sense of aesthetics. Inertia can't be the reason,
since most of us who prefer the single environment were once more familiar
and comfortable with two-cell Lisps. Macros don't have anything to do with
this issue, so macrophobia can't be the reason; if anything, the problems
with Common Lisp-style macros are exacerbated by a single environment.
Speaking for myself, politics isn't the reason I prefer a single
environment; rather my preference for a single environment, the current
preponderance of political clout on the side of multiple environments,
and the use of that clout in the current push for Lisp standards are the
reasons I myself now seek political clout.
* * *
Mike's other question asks whether enough syntactic sugar could be added
to Common Lisp to make functional programming palatable. Well, Common
Lisp certainly could be improved in this respect, and I second David
Moon's remarks on changes 1 and 2.
As for changes 3, 4, and 5, these changes seem designed to make it possible
to program as though Common Lisp were a Lisp1 dialect, but they only go
part of the way. You might be able to go all the way by doing things like
defining the LAMBDA macro so it automatically wraps an equivalent of the
FUNCTIONAL macro around its body, by defining a SET! special form that
assigns to both the value and functional bindings (which, by the way, can't
easily be written in Common Lisp as it stands because only global functional
bindings can be assigned), and so on. This would amount to implementing
a Lisp1 sublanguage inside Common Lisp. Unless you're willing to go
all the way to that Lisp1 sublanguage, I think it's a bad idea to try
to paper over the fact that Common Lisp has multiple environments.
If the changes go only part of the way, and we teach people to use the
proposed syntax and encourage them to think about Common Lisp as though
it is a Lisp1 dialect, then they will probably end up getting burned
even more often than they do now. Even people who understand full well
that Common Lisp has multiple environments might slip into the cozier
Lisp1 mode of thought and get burned by the Lisp2 reality.
It's the law of least astonishment: A Lisp2 dialect that looks like a
Lisp1 dialect 98% of the time may be worse than a straightforward Lisp2
dialect.
Peace,
William Clinger
∂22-Jan-87 1732 RPG March X3J13 Meeting in Palo Alto
To: x3j13@SAIL.STANFORD.EDU
X3J13 Meeting
3/16/87 - 3/19/87
Palo Alto, CA
The third meeting of X3J13 will be held from 1pm, Monday, March 16, 1987
until noon, Wednesday, March 18, 1987, at the Hyatt Rickeys (not to be
confused with the Hyatt Palo Alto across the street) in Palo Alto, CA.
Meetings on Monday and Tuesday will be in the Camino Ball Room C and on
Wednesday the meeting will be in the Executive Conference Room. Come
early, California is beautiful in March.
A block of rooms is available at the Hyatt Rickeys. The rate will be $92 a
night (plus tax). If you prefer, they have rooms available for non-smokers
(ahh, a room never touched by smoke). Please check the appropriate dates
and supply a credit card number if you wish to have the room guaranteed.
Check in time is 3:00pm. Check out time is 12:00 noon. I will be taking
reservations until 2/15/87. After that time please contact Hyatt Rickeys
directly at (800) 228-9000 for reservations and changes. Be sure to
mention ``Standards Committee X3J13'' or ``Lucid.'' Reservations must be
received by the hotel no later than 2/15/87 to receive the discounted rate.
Refreshments will be available during the morning and afternoon sessions.
Lunch has been arranged for Tuesday, March 17. If you have dietary
restrictions please complete the appropriate section below.
The cost per person for food service and conference room rental is $55.00.
Please include a check for this amount, payable to Lucid, with the
registration form.
Delta Airlines has agreed to give us a 35% discount to San Francisco. Call
Delta (or have your travel agent call) toll free at 1 (800) 241-6760 daily
8:30am thru 8:00pm EST. Please refer to file number A0732 when calling.
Tickets must be purchased 14 days in advance, there is no minimum stay, and
the maximum stay is 14 days. Please confirm early as there is limited
seating.
I will be happy to arrange a group dinner at the Thai Garden (a different
eating experience) the evening of March 16 with an extra cost. If you are
interested, please note this in the appropriate space below.
N San Francisco Airport
W E |
S | | 101
------------------------------------------92
| |
| |
| |
| |
| | 101
Foothills | | San Francisco Bay
| |
| |
| |
|X Hyatt Rickey |
| |
|El Camino Real |
| |
Los Altos ----------------------------------------San Antonio Road
| |
| |
Directions from San Francisco airport to Hyatt Rickeys: Take 101 south to
San Antonio Road (about 25 minutes in non-rushhour traffic). Take San
Antonio Road exit marked Los Altos, heading toward the hills. Turn right
on El Camino Real. The hotel is on the right at 4219 El Camino Real, Palo
Alto, CA 94306 (415) 493-0800. Hertz, Avis and National car rentals are
within 1 block.
A shuttle service is available though Airport Connection for $12.00.
Pickup points are located directly outside each terminal baggage claim area
at the center traffic island. Shuttle will stop at each blue striped
pillar. The shuttle stops in Menlo Park, Standford and then Hyatt Rickeys.
The schedule from San Francisco Airport to Palo Alto follows:
* *
LV Menlo Stan- Palo Sunny- San ARR
SFO Park ford Alto vale Jose SJC
7:01A 7:20A 7:35A 7:40A 8:00A 8:25A 8:30A Daily
8:16A 8:40A 8:50A 8:55A 9:20A 9:40A 9:45A Ex. Sat
9:11A 9:35A 9:42A 9:46A 10:05A 10:30A 10:35A Daily
11:00A 11:25A 11:30A 11:35A 12:01P 12:25P 12:30P Ex. Sat
12:01P 12:25P 12:30P 12:35P 1:00P 1:25P 1:30P Daily
1:00P 1:25P 1:30P 1:35P 2:00P 2:25P 2:30P Ex. Sat
2:01P 2:30P 2:35P 2:40P 3:10P 3:40P 3:45P Daily
3:06P 3:35P 3:40P 3:45P 4:10P 4:40P 4:45P Ex. Sat
4:01P 4:30P 4:35P 4:40P 5:05P 5:35P 5:40P Daily
5:20P 5:50P 5:55P 6:00P 6:25P 6:50P 6:55P Ex. Sat
6:50P 7:20P 7:25P 7:30P 7:50P 8:15P 8:20P Daily
8:40P 9:05P 9:10P 9:15P 9:40P 10:00P 10:10P Ex. Sat
10:10P 10:40P 10:45P 10:50P 11:15P 11:35P 11:45P Daily
Shuttle service from Palo Alto to San Francisco Airport:
* *
LV SJC Sunny- Palo Stan- Menlo AR
San Jose vale Alto ford Park SFO
5:25A 5:30A 5:40A 6:08A 6:22A 6:27A 7:00A Daily
6:15A 6:20A 6:35A 7:08A 7:25A 7:30A 8:15A Ex. Sat
7:25A 7:30A 7:45A 8:13A 8:32A 8:37A 9:10A Daily
8:25A 8:30A 8:45A 9:13A 9:32A 9:37A 10:10A Ex. Sat
9:40A 9:45A 9:55A 10:23A 10:37A 10:42A 11:15A Daily
10:30A 10:35A 10:45A 11:08A 11:22A 11:27A 12:05P Ex. Sat
12:25P 12:30P 12:40P 1:08P 1:22P 1:27P 2:00P Daily
1:25P 1:30P 1:40P 2:08P 2:22P 2:27P 3:05P Ex. Sat
2:25P 2:30P 2:40P 3:08P 3:22P 3:27P 4:00P Daily
3:40P 3:45P 3:55P 4:25P 4:44P 4:49P 5:19P Ex. Sat
4:55P 5:00P 5:15P 5:45P 6:05P 6:10P 6:40P Daily
6:50P 6:55P 7:05P 7:30P 7:45P 7:50P 8:20P Ex. Sat
8:15P 8:20P 8:30P 8:55P 9:10P 9:15P 9:45P Daily
Feel free to contact me if you have any questions.
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
edsel!jlz@navajo.stanford.edu
(415) 329-8400
X3J13 March Meeting Registration Form
Please include check for $55.00 payable to Lucid, Inc. mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
Name: _____________________________________________________________
Institution: ______________________________________________________
Street Address: ___________________________________________________
City: ________________ State: ___ Phone: ________________________
Net-Address: ______________________________________________________
Reservations: Mar 15: ___ Mar 16: ___ Mar 17: ___
___ single (1 person) ___ double (2 persons, 1 bed)
___ twin (2 persons, 2 beds) ___ triple (three persons, 2 beds)
The $92.00 room rate is only guaranteed for reservations received by
February 15.
Credit Card: ___ AMEX ___VISA ___ Mastercard ___Diners ___CB
Number: ___________________________________________ Exp ____________
Lunch 3/17: yes _______ no _______
Dietary Restrictions:_______________________________________________
Dinner at Thai Garden 3/16: yes _______ no _______
-rpg-
jlz
∂10-Feb-87 0246 RPG Registration
To: x3j13@SAIL.STANFORD.EDU
Don't forget to register for the March meeting. Registration closes
in a couple of weeks and right now there are only a handful registered.
-rpg-
∂10-Feb-87 2209 RPG Reminder About March Registration Procedure
To: x3j13@SAIL.STANFORD.EDU
X3J13 Meeting
3/16/87 - 3/19/87
Palo Alto, CA
The third meeting of X3J13 will be held from 1pm, Monday, March 16, 1987
until noon, Wednesday, March 18, 1987, at the Hyatt Rickeys (not to be
confused with the Hyatt Palo Alto across the street) in Palo Alto, CA.
Meetings on Monday and Tuesday will be in the Camino Ball Room C and on
Wednesday the meeting will be in the Executive Conference Room. Come
early, California is beautiful in March.
A block of rooms is available at the Hyatt Rickeys. The rate will be $92 a
night (plus tax). If you prefer, they have rooms available for non-smokers
(ahh, a room never touched by smoke). Please check the appropriate dates
and supply a credit card number if you wish to have the room guaranteed.
Check in time is 3:00pm. Check out time is 12:00 noon. I will be taking
reservations until 2/15/87. After that time please contact Hyatt Rickeys
directly at (800) 228-9000 for reservations and changes. Be sure to
mention ``Standards Committee X3J13'' or ``Lucid.'' Reservations must be
received by the hotel no later than 2/15/87 to receive the discounted rate.
Refreshments will be available during the morning and afternoon sessions.
Lunch has been arranged for Tuesday, March 17. If you have dietary
restrictions please complete the appropriate section below.
The cost per person for food service and conference room rental is $55.00.
Please include a check for this amount, payable to Lucid, with the
registration form.
Delta Airlines has agreed to give us a 35% discount to San Francisco. Call
Delta (or have your travel agent call) toll free at 1 (800) 241-6760 daily
8:30am thru 8:00pm EST. Please refer to file number A0732 when calling.
Tickets must be purchased 14 days in advance, there is no minimum stay, and
the maximum stay is 14 days. Please confirm early as there is limited
seating.
I will be happy to arrange a group dinner at the Thai Garden (a different
eating experience) the evening of March 16 with an extra cost. If you are
interested, please note this in the appropriate space below.
N San Francisco Airport
W E |
S | | 101
------------------------------------------92
| |
| |
| |
| |
| | 101
Foothills | | San Francisco Bay
| |
| |
| |
|X Hyatt Rickey |
| |
|El Camino Real |
| |
Los Altos ----------------------------------------San Antonio Road
| |
| |
Directions from San Francisco airport to Hyatt Rickeys: Take 101 south to
San Antonio Road (about 25 minutes in non-rushhour traffic). Take San
Antonio Road exit marked Los Altos, heading toward the hills. Turn right
on El Camino Real. The hotel is on the right at 4219 El Camino Real, Palo
Alto, CA 94306 (415) 493-0800. Hertz, Avis and National car rentals are
within 1 block.
A shuttle service is available though Airport Connection for $12.00.
Pickup points are located directly outside each terminal baggage claim area
at the center traffic island. Shuttle will stop at each blue striped
pillar. The shuttle stops in Menlo Park, Standford and then Hyatt Rickeys.
The schedule from San Francisco Airport to Palo Alto follows:
* *
LV Menlo Stan- Palo Sunny- San ARR
SFO Park ford Alto vale Jose SJC
7:01A 7:20A 7:35A 7:40A 8:00A 8:25A 8:30A Daily
8:16A 8:40A 8:50A 8:55A 9:20A 9:40A 9:45A Ex. Sat
9:11A 9:35A 9:42A 9:46A 10:05A 10:30A 10:35A Daily
11:00A 11:25A 11:30A 11:35A 12:01P 12:25P 12:30P Ex. Sat
12:01P 12:25P 12:30P 12:35P 1:00P 1:25P 1:30P Daily
1:00P 1:25P 1:30P 1:35P 2:00P 2:25P 2:30P Ex. Sat
2:01P 2:30P 2:35P 2:40P 3:10P 3:40P 3:45P Daily
3:06P 3:35P 3:40P 3:45P 4:10P 4:40P 4:45P Ex. Sat
4:01P 4:30P 4:35P 4:40P 5:05P 5:35P 5:40P Daily
5:20P 5:50P 5:55P 6:00P 6:25P 6:50P 6:55P Ex. Sat
6:50P 7:20P 7:25P 7:30P 7:50P 8:15P 8:20P Daily
8:40P 9:05P 9:10P 9:15P 9:40P 10:00P 10:10P Ex. Sat
10:10P 10:40P 10:45P 10:50P 11:15P 11:35P 11:45P Daily
Shuttle service from Palo Alto to San Francisco Airport:
* *
LV SJC Sunny- Palo Stan- Menlo AR
San Jose vale Alto ford Park SFO
5:25A 5:30A 5:40A 6:08A 6:22A 6:27A 7:00A Daily
6:15A 6:20A 6:35A 7:08A 7:25A 7:30A 8:15A Ex. Sat
7:25A 7:30A 7:45A 8:13A 8:32A 8:37A 9:10A Daily
8:25A 8:30A 8:45A 9:13A 9:32A 9:37A 10:10A Ex. Sat
9:40A 9:45A 9:55A 10:23A 10:37A 10:42A 11:15A Daily
10:30A 10:35A 10:45A 11:08A 11:22A 11:27A 12:05P Ex. Sat
12:25P 12:30P 12:40P 1:08P 1:22P 1:27P 2:00P Daily
1:25P 1:30P 1:40P 2:08P 2:22P 2:27P 3:05P Ex. Sat
2:25P 2:30P 2:40P 3:08P 3:22P 3:27P 4:00P Daily
3:40P 3:45P 3:55P 4:25P 4:44P 4:49P 5:19P Ex. Sat
4:55P 5:00P 5:15P 5:45P 6:05P 6:10P 6:40P Daily
6:50P 6:55P 7:05P 7:30P 7:45P 7:50P 8:20P Ex. Sat
8:15P 8:20P 8:30P 8:55P 9:10P 9:15P 9:45P Daily
Feel free to contact me if you have any questions.
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
edsel!jlz@navajo.stanford.edu
(415) 329-8400
X3J13 March Meeting Registration Form
Please include check for $55.00 payable to Lucid, Inc. mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
Name: _____________________________________________________________
Institution: ______________________________________________________
Street Address: ___________________________________________________
City: ________________ State: ___ Phone: ________________________
Net-Address: ______________________________________________________
Reservations: Mar 15: ___ Mar 16: ___ Mar 17: ___
___ single (1 person) ___ double (2 persons, 1 bed)
___ twin (2 persons, 2 beds) ___ triple (three persons, 2 beds)
The $92.00 room rate is only guaranteed for reservations received by
February 15.
Credit Card: ___ AMEX ___VISA ___ Mastercard ___Diners ___CB
Number: ___________________________________________ Exp ____________
Lunch 3/17: yes _______ no _______
Dietary Restrictions:_______________________________________________
Dinner at Thai Garden 3/16: yes _______ no _______
-rpg-
jlz
∂13-Feb-87 1948 MATHIS@ADA20.ISI.EDU plans for Palo Alto and mailing
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 13 Feb 87 19:46:39 PST
Date: 12 Feb 1987 11:35-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: plans for Palo Alto and mailing
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]12-Feb-87 11:35:35.MATHIS>
Today I put the following in the US mail to our physical mailing list.
Most of the documents referenced can also be had electronically. Two
items of particular interest follow -- the cover letter and the DRAFT
agenda (please send me any further detail you may have for a revised
agenda):
Doc. No.: X3J13/87-006
Date: 87-02-10
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
To X3J13 (Common Lisp) participants:
Enclosed are some of the documents relating to the upcoming
meeting in Palo Alto, CA on March 16-18, 1987. Most of you are on
the electronic mailing list and should have seen most of this
earlier. In particular hotel reservations are due about the time
you will probably receive this letter.
Dick Gabriel will be sending out information relative to the
objects proposal separately and directly [documents 87-002 and
87-003].
Notice that there is a revised version of Doc: 86-020 on Purposes
included with document 86-023. This includes some of the comments
that I saw on the net reproduced in a way that will hopefully
facilitate their consideration. If you have other comments or
changes that you may want to suggest at the meeting, please bring
about 50 copies for distribution there. I expect some action will
be taken on this document at the meeting.
Documents 86-017 and 86-018 are from the infamous lost boxes of
Dallas.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
Enclosures:
86-017 Excerpts from ISO/TC97/SC22 ad hoc report re Lisp
86-018 Papers from Symbolics re objects and flavors
86-019 from Mike Beckerle
86-020R included with 86-023
86-023 Comments on Purposes document 86-020
86-024 Comments on Lisp1/Lisp2 issues
87-000 Document Register for 1987
87-001 Document Register for 1986
87-004 Palo Alto Meeting Announcement
87-005 Draft Agenda for Palo Alto Meeting
SD-04 Meeting Schedule
Note: 87-002 and 87-003 being mailed separately.
Proposed Agenda X3J13/87-005
AGENDA -- Day 1
X3J13 (Common Lisp) Third Meeting, March 16-18, 1987
Hyatt Rickeys, Palo Alto, CA
1 Call to Order, March 16, 1:00pm
2 Opening Remarks and Introductions
3 Approval of Agenda (87-005)
4 Approval of Minutes of Sept 23-24 Meeting (Doc: 86-025)
5 Approval of Minutes of Dec 10-12 Meeting (Doc: 86-021)
6 Report on International Activities (Doc: 86-017)
7 Other Liaison Reports
8 Action on Goals and Objectives (Doc: 86-020R and 86-023)
9 Reports from Task Group Chairmen
10 Recess, 5:00pm
AGENDA -- Day 2
X3J13 (Common Lisp) Third Meeting, March 16-18, 1987
Hyatt Rickeys, Palo Alto, CA
11 Call to Order, March 17, 9:00am
12 Discussion of Objects Proposal (87-002 and 87-003)
13 LUNCH Second Day, 12:00-1:00pm
14 Continued Objects Discussion (87-002 and 87-003)
15 Recess, 5:00pm
AGENDA -- Day 3
X3J13 (Common Lisp) Third Meeting, March 16-18, 1987
Hyatt Rickeys, Palo Alto, CA
16 Call to Order, March 18, 9:00am
17 Additional Reports from Task Group Chairmen
18 Future Meeting Schedule (Doc: SD-04)
19 Review of Action Item Assignments
20 Adjournment, 12:00noon
∂27-Feb-87 1453 RPG X3 registration list 2/27/87
To: x3j13@SAIL.STANFORD.EDU
Below is the list of people I have heard from, hotel dates and
whether registration fees have been paid. Please check the
list and let me know if you disagree with any information about
yourself.
---jan---
Registration/Hotel List
02/27/87
Name Company Check In Check Out Paid
David Bartley TI 03/15/87 03/18/87 y
Michael Beckerle Gold Hill -0- -0- y
Eric Benson Lucid, Inc. -0- -0- -
Daniel Bobrow Xerox PARC -0- -0- y
Mary Boelk Johnson Controld, 03/15/87 03/18/87 y
Skona Brittain MSC -0- -0- -
Gary Brown Digital 03/15/87 03/18/87 y
Jerome Chailloux INRIA -0- -0- -
Christopher Dabrowski National Bureau of 03/16/87 03/18/87 y
Jeff Dalton AI Application 03/15/87 03/18/87 -
Linda DeMichiel Lucid, Inc. -0- -0- -
Patrick Dussud Texas Instruments 03/15/87 03/18/87 y
Susan Ennis AMOCO Production 03/15/87 03/18/87 y
Scott Fahlman CMU 03/14/87 03/18/87 y
John Foderaro Franz Inc. -0- -0- y
Dick Gabriel Lucid, Inc. -0- -0- -
Robert Giansiracusa Red Shark Software -0- -0- y
George Hadden Honeywell 03/16/87 03/18/87 y
Steve Haflich Franz Inc. -0- -0- y
Masayuki Ida Aoyama Gakuin 03/14/87 03/19/87 -
Kevin Layer Franz Inc. -0- -0- y
Bob Mathis DARPA 03/14/87 03/19/87 y
Ronald Ohlander USC/ISI -0- -0- y
Crispin Perdue SUN MicroSystems -0- -0- y
Bill Scherlis DARPA 03/15/87 03/18/87 -
David Slater Computer Sciences 03/15/87 03/17/87 y
S. Sridhar Tektronix, Inc. -0- -0- y
Guy Steele Thinking Machines, 03/15/87 03/18/87 y
Thomas Turba UNISYS 03/15/87 03/18/87 y
Ellen Waldrum TI 03/15/87 03/18/87 y
JonL White Lucid, Inc. -0- -0- -
Alexis Wieland MITRE 03/16/87 03/18/87 y
∂27-Feb-87 1513 ohlander@venera.isi.edu Re: X3 registration list 2/27/87
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 27 Feb 87 15:13:46 PST
Posted-Date: Fri 27 Feb 87 15:14:12-PST
Received: by venera.isi.edu (5.54/5.51)
id AA03315; Fri, 27 Feb 87 15:14:12 PST
Date: Fri 27 Feb 87 15:14:12-PST
From: Ron Ohlander <OHLANDER@venera.isi.edu>
Subject: Re: X3 registration list 2/27/87
To: RPG@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
Message-Id: <VAX-MM(195)+TOPSLIB(124) 27-Feb-87 15:14:12.VENERA.ISI.EDU>
In-Reply-To: Message from "Dick Gabriel <RPG@SAIL.STANFORD.EDU>" of 27 Feb 87 1453 PST
Dick,
I will check in on the evening of the 17th of March and check out on the 18th
of March. I have made my room reservation independently.
Ron
-------
∂03-Mar-87 1251 berman@vaxa.isi.edu Re: Who's Where?
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 3 Mar 87 12:51:19 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA17152; Tue, 3 Mar 87 12:51:59 pst
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8703032051.AA17152@vaxa.isi.edu>
Date: 3 Mar 1987 1251-PST (Tuesday)
To: berman@vaxa.isi.edu (Richard Berman)
Cc: X3J13@su-ai.arpa
Subject: Re: Who's Where?
In-Reply-To: My message of 2 Mar 1987 1332-PST (Monday).
<8703022132.AA05893@vaxa.isi.edu>
A few days ago I asked for the members of the X3J13 subgroup on validation to
please send me their current net address as part of a message (as opposed to
just having the mailer automatically generate one). So far Mike Beckerle and
John Foderaro have responded. Could Jon L. White and David Slater please
respond, as well as any others???
Thanks a bunch.
RB
∂03-Mar-87 1359 berman@vaxa.isi.edu Validation
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 3 Mar 87 13:59:30 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA17899; Tue, 3 Mar 87 13:59:42 pst
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8703032159.AA17899@vaxa.isi.edu>
Date: 3 Mar 1987 1359-PST (Tuesday)
To: Marick@GSWD-VMS.ARPA
Cc: berman@vaxa.isi.edu, cl-validation@su-ai.arpa, X3J13@SU-AI.arpa
Subject: Validation
> I'm not going to respond to your message until you respond to mine.
> I just spent a weekend rewriting sequence function tests and,
> consequently, rewriting some sequence functions. I am more convinced
> than ever that a test suite should predate publication of a standard
> -- there's at least one other sequence function besides *ASSOC* that's
> underspecified. (Unfortunately, I didn't write it down, and I've
> forgotten which one, now.)
> Does the deafening silence mean consent?
Brian, let me know if this gets through. I have been responding to messages,
but sending them to marrick%cthulhu@gswd-vms.arpa has not worked.
I don't know that a test suite should *predate* standard publication, but it
should be part of that publication. In fact, when formally published it would
be a good idea to for the standard and the test-suite to cross reference each
other. That is, the each test should test a specific clause (or clauses?) of
the standard. The standard should also include forms which must evaluate in a
certain way where this is meaningful to the definition of some part of the
standard. In these cases the form would be part of the test suite.
HOWEVER....
I believe it is possible to have a useful test suite before the standard is
finalized and published. I am preparing a report now for the X3 meeting that
will outline some possible stages in the development of the test suite. Part
of our problem is that we are aiming at a moving target...
Best,
RB
∂07-Mar-87 1414 MATHIS@ADA20.ISI.EDU agenda update
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 7 Mar 87 14:14:45 PST
Date: 7 Mar 1987 14:15-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: agenda update
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU] 7-Mar-87 14:15:02.MATHIS>
Although I will not be making a revised agenda, on Monday, March
16, we will be having a report from Masayuki Ida on activities in
Japan, a report from Bob Balzer and Rich Berman on validation
developments, and I expect an initial report from the clean-up
committee which will probably continue on Wednesday morning. If
any of you have any last minute things to let me know about,
please send net mail before Saturday morning or contact me at the
hotel beginning Sunday. -- Bob
∂12-Mar-87 2210 RPG Final Attendee List
To: x3j13@SAIL.STANFORD.EDU
Here is the current list. See you Monday!
Registration/Hotel List
03/12/87
Name Company Check In Check Out Paid
John Allen The Lisp Co. -0- -0- y
David Bartley TI 03/15/87 03/18/87 y
Michael Beckerle Gold Hill -0- -0- y
Eric Benson Lucid, Inc. -0- -0- -
Richard Berman USC/ Information 03/16/87 03/19/87 y
Daniel Bobrow Xerox PARC -0- -0- y
Mary Boelk Johnson Controld, 03/15/87 03/18/87 y
Skona Brittain MSC -0- -0- y
Gary Brown Digital 03/15/87 03/18/87 y
Mike Cannon Hewlett-Packard -0- -0- y
Jerome Chailloux INRIA -0- -0- -
Chip Chapin Hewlet-Packard -0- -0- y
William Clinger Tektronics 03/16/87 03/18/87 y
Peter Coffee Aerospace Corp. 03/16/87 03/17/87 -
Pavel Curits Xerox AIS -0- -0- y
Christopher Dabrowski National Bureau of 03/16/87 03/18/87 y
Jeff Dalton AI Application 03/15/87 03/18/87 y
Andrew Daniels Xerox AIS -0- -0- y
Linda DeMichiel Lucid, Inc. -0- -0- -
Patrick Dussud Texas Instruments 03/15/87 03/18/87 y
Susan Ennis AMOCO Production 03/15/87 03/18/87 y
Scott Fahlman CMU 03/14/87 03/18/87 y
John Foderaro Franz Inc. -0- -0- y
Dick Gabriel Lucid, Inc. -0- -0- -
Robert Giansiracusa Red Shark Software -0- -0- y
George Hadden Honeywell 03/16/87 03/18/87 y
Steve Haflich Franz Inc. -0- -0- y
Jed Harris Intel -0- -0- y
Liz Heron IBM -0- -0- -
Carl Hewitt MIT 03/15/87 03/19/87 y
Masayuki Ida Aoyama Gakuin 03/14/87 03/19/87 -
Sonya Keene Symbolics, Inc. -0- -0- y
Jim Kempf Hewlett-Packard -0- -0- y
Gregor Kiczales Xerox PARC -0- -0- -
Kevin Layer Franz Inc. -0- -0- y
Jim Lin IBM -0- -0- -
Thom Linden IBM -0- -0- y
Barry Margolin Thinking Machines 03/15/87 03/19/87 -
Larry Masinter Xerox PARC -0- -0- y
Bob Mathis 03/14/87 03/19/87 y
David Matthews Hewlett Packard -0- -0- y
David Moon Symbolics, Inc. -0- -0- y
Ronald Ohlander USC/ISI 03/17/87 03/18/87 y
Bob Pellegrino Prime Computer, 03/15/87 03/19/87 y
Crispin Perdue SUN MicroSystems -0- -0- y
Kent Pitman Symbolics -0- -0- y
Bill Scherlis DARPA 03/15/87 03/18/87 -
David Slater Computer Sciences 03/15/87 03/17/87 y
Angela Sodan GMD -0- -0- y
S. Sridhar Tektronix, Inc. -0- -0- y
Guy Steele Thinking Machines, 03/15/87 03/18/87 y
Thomas Turba UNISYS 03/15/87 03/18/87 y
Ellen Waldrum TI 03/15/87 03/18/87 y
Mark Wegman IBM T.J. Watson -0- -0- y
Dan Weinreb Symbolics, Inc. -0- -0- y
JonL White Lucid, Inc. -0- -0- -
Alexis Wieland MITRE 03/16/87 03/18/87 y
∂13-Mar-87 0204 brown%bizet.DEC@decwrl.DEC.COM Technical Editor
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 13 Mar 87 02:04:49 PST
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
id AA08145; Fri, 13 Mar 87 02:05:31 PST
Message-Id: <8703131005.AA08145@decwrl.dec.com>
Date: Friday, 13 Mar 1987 02:03:29-PST
From: brown%bizet.DEC@decwrl.DEC.COM
To: x3j13@SAIL.STANFORD.EDU
Subject: Technical Editor
The major conclusion arrived at from thinking about writing the
standard is that a technical editor is required. This person's
job would be to convert CLTL to an approved format, distribute
copies, and incorporate approved changes and new material - basically
to control the sources to the standard. This is clearly a full-time job.
DEC is willing to hire someone to do this job for, at least, the
first year. However, before hiring someone to do it, we need to know
if this is acceptable to the committee. Please consider this offer,
and let me know when we meet next week.
-Gary Brown
∂13-Mar-87 0852 RPG Writer
To: x3j13@SAIL.STANFORD.EDU
This is the kind of spirit of volunteerism that is required to
make our task succeed. I encourage others to note this offer and
consider what they themselves can do.
Because this committee as a whole has oversight over the writer,
I can see no objections whatever. Possibly we'll want to nominate
an editor or two to work with the writer and exercise immediate
direction?
-rpg-
∂18-Mar-87 1341 MATHIS@ADA20.ISI.EDU draft minutes Palo Alto meeting
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 18 Mar 87 13:40:27 PST
Date: 18 Mar 1987 13:40-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: draft minutes Palo Alto meeting
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU]18-Mar-87 13:40:53.MATHIS>
These are still quite rough, but Mary and I wanted to get them out fast.
Please send me your reactions and comments.
1:00pm ITEM 1 - Monday, March 16, 1987. Palo Alto meeting called to order.
ITEM 2 -Mathis - introductory remarks. New documents and missing Dallas
documents made available. Attendance book sent around. Introduction of
attendees.
ITEM 3 - March 16 agenda (X3J13/87-006) rearranged to bring forward points 8
and 9.
ITEM 4 - Sept 23-24 minutes (X3J13/86-025) sent out but had typos in names.
Corrections to other minutes will be noted in minutes of March 16-18
(X3J13/87-016)
ITEM 5 -Dec 10-12 minutes (X3J13/86-021) not yet available but should be
available by end of meeting.
ITEM 6
ISO ballot has been sent in, but the meeting is not planned until summer.
Anyone interested in joining the ISO working group is asked to contact Bob
Mathis. The size of the US delegation is planned to be about 6 people.
1:25pm ITEM 8 - Purposes of X3J13 Committee (X3J13/86-023 (revision of
X3J13/86-020))
1.
a. Guy Steele suggests changing "extensions" to "additional features".
Informal voice vote unanimously in favor.
b. Dave Moon concerned about phrase, "establishing normative practice".
Informal voice vote unanimously in favor of dropping phrase altogether.
"X3J13 is chartered to produce an American National Standard for Common
Lisp. It will codify existing practice and provide additional features to
facilitate portability of code among diverse implementations."
2.
a. Dave Matthews asks whether aesthetic criteria should exist at all.
Informal voice vote shows majority in favor of change in wording. Informal
voice vote unanimously in favor of Guy Steele's proposed wording change.
"The committee will begin with the language described in Common Lisp: The
Language by Guy L. Steele Jr. (Digital Press, 1984), which is the current
de facto standard for Common Lisp. Whenever there is a proposal for the
standard to differ from Common Lisp: The Language, the committee shall
weigh both future costs of adopting (or not adopting) a change and the
costs of conversion of existing code. Aesthetic considerations shall
also be weighed, but as subordinate criteria."
2:30pm - Comments by John McCarthy. Comments will be put into
future article for Lisp Pointers.
2:35pm - Break
ITEM 9 - Reports from Task Group Chairpeople
2:50pm - Bob Balzer, Rich Berman (ISI) - Validation Suite
Rich Berman described the current status of the test suite design. Format has
been designed and 550 tests converted into that format.
Bob Balzer described how ISI could run the test suite against a particular
implementation and produce a report of the results. The process is currently in
the Ad-hoc Stage for evaluation. Later stages will result in a managed test
suite. The effort is estimated to take 3.5 person-years to produce 25,000
normalized cases.
Discussion identified concern over the final use of the test suite (ie., for
implementors or for users), and over the extent of the effort devoted to
resolution of ambiguity in the language standard showed up by test cases.
The topic will be continued on Wednesday.
4:25pm - Professor Ida - Lisp Activities in Japan (X3J13/87-007)
4:40pm - Gary Brown (DEC)
Gary Brown has received permission from DEC to hire a technical writer to do
the actual creation of the standard, with copyright held by ANSI. The response
of the committee was enthusiastic applause.
4:50pm - Larry Masinter (Xerox) - Cleanup Committee
Current status (X3J13/87-010) describes status as of March, 1987 rather than
May, 1987. Distribution of language suggestions and changes through computer
networks was discussed, but not resolved. The discussion will be continued
Wednesday.
5:10pm - Meeting adjourned.
Tuesday, March 17, 1987. Palo Alto meeting called to order.
9:05am - Dan Bobrow, Opening Remarks
Common Lisp Object System Specification
1. Programmer Interface Concepts (X3J13/87-002)
2. Functions in the Programmer Interface (X3J13/87-002)
3. Meta Object Protocol (X3J13/87-003)
4. Glossary (X3J13/87-008)
5. Corrections and Amendments (X3J13/87-009)
9:10am - David Moon, "Common Lisp, Object System"
10:35am - Break
11:00am - Gregor Kiczales, "Programming with Meta-Objects"
1:05pm - Lunch Break
2:45pm - Dan Bobrow, "Meta Object Protocol"
4:00pm - Break
4:25pm - Questions and Answers on previous presentations
The discussion resulted in the decision to vote Wednesday morning on the X3J13
position on the work done to date on the Common Lisp Object System
Specification.
5:50pm - Meeting adjourned.
Wednesday, March 18, 1987. Palo Alto meeting called to order.
9:05am - Peter Coffee presented the wording of a motion which reflected the
discussion of Tuesday afternoon. The X3J13 committee unanimously voice voted
to have this moved. A majority voice vote determined that the motion would be
presented as three separate items with X3J13 document references.
On a motion by Peter Coffee, and a second by Mark Wegman, the
following formal motion was passed by unanimous voice vote.
Resolved by the National Technical Committee for Standardization of
Lisp (X3J13):
(1) The committee believes that object-oriented programming
will be incorporated as part of a future Common Lisp standard;
(2) The committee believes that Chapters 1 and 2 of the Common Lisp
Object System (CLOS) specification (collectively, X3J13 document 87-002)
captures the essentials of the future standard object facility.
The committee also looks forward to a refined version of CLOS
Chapter 3 (X3J13/87-003) that will similarly reflect the
essentials of a standard meta-object facility;
(3) The committee encourages experimentation with the object
system reflected in CLOS Chapters 1-3.
SUBCOMMITTEE REPORTS
9:30am - Jon L. White - Iteration Subcommittee
JonL described the work done to date of the committee on identifying several
iteration paradymes, and will create a preliminary document for distribution.
9:35am - Kent Pitman - Macros; Errors and Conditions Subcommittee
Kent described the continuing work on xx (X3J13/xxx), and felt that the work
was beginning to converge. It is expected that the converged design will
be presented at the next meeting.
9:40am - Rich Berman - Validation and Conformance Subcommittee
Rich summarized the presentation which he gave on Monday.
9:45am - Gary Brown - Presentation of Standard Subcommittee
Gary reiterated that the standard will be controlled by ANSI rules. The actual
creation of the document will be done by a technical writer who will be hired
by DEC. The text editing system used for this document will be TEX.
An editorial subcommmittee has been formed. The current volunteers are
Pavel, Margolin, Slater, Fahlman, Weinreb, Pitman, Linden, Ennis, and Ida.
Gary suggested that a formal definition of some parts of Common Lisp would
be valuable. The response of the committee indicated that further discussion
of this issue was needed.
10:05am - Dan Bobrow - Objects Subcommittee
Dan thanked the committee for their feedback on the CLOS design.
10:07am - Dick Gabriel - Lisp 1/Lisp 2 Subcommittee
The topic has been temporarily quiescent, due to subcommittee members
being involved elsewhere.
10:10am - Steve Haflich - Compiler Specification Subcommittee.
A large amount of work has been done on a specification document. The subcommittee is intending to stop and look at
the more global issues of what their task encompasses and how they should
approach the problems.
10:20am - Bob Mathis - NEXT MEETING PLANNING
The consensus of the committee was to have a two full day meeting on
Tuesday (10am - 6pm) and Wednesday (9am - 4pm), June 30th and July 1st.
Subcommittees were encouraged to meet on Monday afternoon.
10:35am - Break
11:00am - Bob Mathis - FUTURE MEETING PLANNING
Susan Ennis has agreed to act as a clearinghouse for information on
possible meeting sites and times.
ll:00am - Larry Masinter - Cleanup Subcommittee
Bob Mathis will create a message to the Common Lisp mailing list describing the
standardization process. He will reiterate that the X3J13 committee is open,
but that it is only within X3J13 that the technical discussions will occur.
The discussion considered the ways in which the cleanup proposals would be
presented to the committee for final voting. When proposals are presented
in the future, Larry will identify those which are potentially controversial.
Proposals will be presented to the committee in advance of the meeting.
After a proposal has been accepted, the editorial committee will give
direction to the technical writer for incorporation into the standard.
12:00 noon - Final Meeting Adjournment
∂18-Mar-87 1342 MATHIS@ADA20.ISI.EDU meeting documents
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 18 Mar 87 13:42:25 PST
Date: 18 Mar 1987 13:43-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: meeting documents
Subject: [MATHIS@ADA20.ISI.EDU: minutes first meeting]
Subject: [MATHIS@ADA20.ISI.EDU: document register]
Subject: [MATHIS@ADA20.ISI.EDU: Purposes document]
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]18-Mar-87 13:43:03.MATHIS>
These messages were printed and distributed Wednesday morning at the meeting.
Begin forwarded messages
Received: By ADA20.ISI.EDU via direct-append with Hermes; 17 Mar 87 23:04:40-PST
Date: 17 Mar 1987 23:04-PST
From: MATHIS@ADA20.ISI.EDU
To: edsel!jlz@NAVAJO.STANFORD.EDU
Cc: rpg@SAIL.STANFORD.EDU, Mathis@ADA20.ISI.EDU
Subject: minutes first meeting
Message-ID: <[ADA20.ISI.EDU]17-Mar-87 23:04:37.MATHIS>
Sender: MATHIS@ADA20.ISI.EDU
DRAFT Minutes X3J13 Committee Meeting
Dates: September 23-24, 1986
Location: CBEMA Headquarters, Washington, DC
Chair: Bob Mathis (acting)
Secretary: Steve Haflich (acting)
Hour of opening: September 23, 1986, 9:00 AM
Hour of adjournment: September 24, 1986, 3:00 PM
List of Voting members: Attached
Approved Agenda: Attached (86-0016)
Approval of previous minutes: None (this was first meeting)
Register of Documents: Attached
Motions seconded and not withdrawn:
Future meeting schedule:
The next meeting is scheduled for Decmeber 10-12, 1986, in
Dallas, TX. Ellen Waldrum will make the arrangements.
List of action items assigned to committee members:
Mathis will contact DEC Press about using the Steele book as a
basis for the standard
The meeting was called to order at 10:00 AM, September 23, 1986.
The agenda, X3J13/86-001, was approved without objection.
Catherine Kachuric, Director of the X3 Secretariat presented a
tutorial on the organization and operation of X3. Most of the
details are codified in the X3/SD-2 operating document which was
distributed at the meeting.
Mathis led a discussion of meeting procedures:
1. by consensus it was decided there will be no smoking in
X3J13 meeting rooms;
2. each meeting will focus on one or more technical issues
with prepared presentations, it is necessary that the
membership be well prepared technically in advance of
meetings so that final discussions and voting can be
facilitated during scarce meeting time;
3. Gabriel will set up a new mailing list which will function
as a subset of the existing COMMON-LISP@SAIL.STANFORD.EDU,
and therefore nothing should be sent to both lists. Also,
anything with a time limit for action should be sent to
X3J13, not COMMON-LISP, as not all members will read the
latter in a timely fashion. Addresses are:
X3J13@SAIL.STANFORD.EDU
X3J13-REQUEST@SAIL.STANFORD.EDU
RPG@SAIL.STANFORD.EDU
4. Mathis can be reached at MATHIS@B.ISI.EDU. Since only a
few members lack internet access, the committee will
consider using electronic mail for discussion. Mathis will
attempt to arrange network access for members in need.
All written X3 subcommittee communications are distributed to
everybody and are filed as part of the official records. There
was discussion whether this would apply to electronic mail to
x3j13@Stanford. Some people feel that network comments are made
informally and are similar to oral communications; therefore,
they should not be available as a written record. There was a
conflicting desire that the archives be publically available
(e.g. via FTP) since this has proven useful with
COMMON-LISP@STANFORD. It was provisionally agreed that the
archives would be maintained, but for now they would not be
publically accessible.
There was further discussion of how to bypass one of the
shortcomings of electronic communication -- the volume of the
archive makes it a poor reference source and decisions can get
lost. Therefore, it was oproposed that when discussion on a point
dies down there should be a summarization of discussion placed in
a small, more readable ledger and this document would be recorded
and distributed by X3J13.
Mathis requested a committee to further consider the use of
network communication: Mathis, Pitman, Fahlman, Rosenking, and
Haflich.
Mathis led a discussion of the project proposal (subsequently
given the number X3J13/SD-2.
The title is "Common Lisp" rather than "Lisp" although this could
be changed with little effort. The scope of the committee is one
of the items that will have to be decised. There was general
agreement that we are standardizing Common Lisp, not all Lisp for
all time. Gabriel informed the meeting that McCarthy objects to
our using plain "Lisp." It is intended that X3J13 will subsume
the less formal technical committee formed after the December
1985 Boston meeting.
Several parties were interested in the relationship with Digital
Press over rights to use the Steele book. Considerable discussion
occurred with the eventual result that Mathis would work directly
with Digital Press to make appropriate arrangements.
After a lunch recess, the meeting reconvened at 2:30 PM.
Dan Bobrow made an introductory presentation on Common Loops.
[The preliminary document for this presentation was 86-004 and
the slides from it were distributed as 86-006.] Discussion of
Common loops followed, particularly regarding the nature of a
specification and the best process for arriving at one. There
will be a small meeting at OOPSLA on the current proposal and a
new draft will follow.
Mathis reported that Mary van Deusen has volunteered to produce
an unedited Lisp newsletter in the same manner that she produced
the original Ada newsletter. It was also noted that Gabriel and
Steele will also be editing a professional refereed quarterly for
Kliewer. Both publications felt there was no conflict.
There was some technical discusison of removing function-value
cell separation from Common Lisp. Discussion was started
explicitly to serve a s a trial vehicle to focus on the extent to
which the committee would be willing to make changes that would
disrupt the installed base. This discussion will be continued at
future meetings.
A subcommittee, chaired by Ennis, was formed to develop a draft
document for the proposed scope and purposes of X3J13. They met
over dinner and during the evening. Their draft [86-005] was
presented the next morning.
The meeting was recessed on September 23, 1986 at 5:15 PM.
The meeting was resumed on September 24, 1986 at 9:00 AM.
Steele led a discussion of his two documents relating to SD-1
[Common Lisp: The Language] which were first distributed at the
December 1985 Common Lisp community meeting [86-002 and 86-003].
The intention is that once a version of 86-002 is approved, all
references to SD-1 will mean the Steele book "as corrected."
There was considerable discussion on the various topics, but no
specific issues were resolved at the meeting.
After a lunch recess, the meeting reconvened at 1:00 PM.
Mathis led a discussion of a potential meeting schedule. Several
offers were made including MCC Austin, MIT Boston, and TI Dallas.
After a discussion of optimizing meeting location, timing,
length, etc., it was decisded to meet in Dallas, December 10-12.
There was also sentiment expressed for the next meeting to be in
Palo Alto and the one after that in Boston.
Mathis asked the following to serve as an agenda committee for
the next meeting: Mathis, Fahlman, Gabriel, Purdue, Ennis,
Steele, and Scherlis. Furthermore, these items were suggested as
natural for the next agenda:
-- studying the possibility of merging symbol function cells
in Common Lisp with value cells (like Scheme),
-- Pitman will presnet the error system proposal,
-- further consideration of the current scoping and
declaration issues (the intention is to devise a proposal
over the network to be disteributed before the meeting),
-- the ongoing negotiations with ISO.
The meeting was adjourned on September 24, 1986 at 3:00 PM.
Respectfully Submitted,
Steve Haflich and Bob Mathis
--------------------
Received: By ADA20.ISI.EDU via direct-append with Hermes; 17 Mar 87 23:10:04-PST
Date: 17 Mar 1987 23:10-PST
From: MATHIS@ADA20.ISI.EDU
To: edsel!jlz@NAVAJO.STANFORD.EDU
Cc: rpg@SAIL.STANFORD.EDU, Mathis@ADA20.ISI.EDU
Subject: document register
Message-ID: <[ADA20.ISI.EDU]17-Mar-87 23:10:01.MATHIS>
Sender: MATHIS@ADA20.ISI.EDU
Standing Documents (date of latest revision)
SD-01 Common Lisp: The Language, Guy L. Steele Jr., Digital
Press, 1984.
SD-02 Common Lisp Project Prosal to SPARC (86.02.18)
SD-03 Current Membership List of X3J13 (in preparation)
SD-04 Meeting Schedule (87.02.10)
SD-05 Purposes of X3J13 Committee (87.03.16)
This year's Documents
87-000 Document Register for 1987 (87.03.17)
87-001 Document Register for 1986 (87.02.10)
87-002 Objects Chapter 1 & 2
87-003 Objects Chapter 3
87-004 Palo Alto Meeting Announcement
87-005 Draft Agenda for Palo Alto Meeting
87-006 Cover letter dated 87.02.10 which included 86-017,
86-018, 86-019, 86-020R, 86-023, 86-024, 87-000, 87-001,
87-004, 87-005, SD-04.
87-007 A Progress Report on the Common Lisp Related Activities
in Japan by Masayuki Ida.
87-008 Common Lisp Object System Specification Glossary
87-009 Common Lisp Object System Specification Corrections and
Amendments to the Document
87-010 Cleanup Committee Report
87-011 "Encapsulation and Inheritance in Object-Oriented
Programming Languages" by Alan Snyder, OOPSLA, 1986.
87-012 Slides from David Moon's presentation 87.03.17
87-013 Slides from Gregor Kiczales's presentation 87.03.17
87-014 Slides from Danny Bobrow's presentation 87.03.17
87-015 Further reactions to 86-019
87-016 Draft Minutes Palo Alto meeting 87.03.16-18
87-017 Cover letter dated 87.03.29 which included
87-018
87-019
Next year's Documents
88-000 Document Register for 1988
88-001 Document Register for 1987
88-002
--------------------
Received: By ADA20.ISI.EDU via direct-append with Hermes; 17 Mar 87 23:14:39-PST
Date: 17 Mar 1987 23:14-PST
From: MATHIS@ADA20.ISI.EDU
To: edsel!jlz@NAVAJO.STANFORD.EDU
Cc: rpg@SAIL.STANFORD.EDU, Mathis@ADA20.ISI.EDU
Subject: Purposes document
Message-ID: <[ADA20.ISI.EDU]17-Mar-87 23:14:37.MATHIS>
Sender: MATHIS@ADA20.ISI.EDU
X3J13/SD-05 Purposes of X3J13 Committee (87.03.16)
1. X3J13 is chartered to produce an American National Standard
for Common Lisp. It will codify existing practice and provide
additional features to facilitate portability of code among
diverse implementations.
2. The committee will begin with the language described in Common
Lisp: The Language by Guy L. Steele Jr. (Digital Press, 1984),
which is the current de facto standard for Common Lisp. Whenever
there is a proposal for the standard to differ from Common Lisp:
The Language, the committee shall weigh both future costs of
adopting (or not adopting) a change and costs of conversion of
existing code. Aesthetic considerations shall also be weighed,
but as subordinate criteria.
3. The committee will address at least the following topics in
the course of producing the standard, in each case either
incorporating specific features or explaining why no action was
taken:
(a) Repairing mistakes, ambiguities, and minor ommissions
in Common Lisp: The Language
(b) Error handling and condition signalling
(c) Semantics of compilation
(d) Object-oriented programming
(e) Iteration constructs
(f) Multiprocessing
(g) Graphics
(h) Windows
(i) Validation
(j) One versus two namespaces for functions and variables
Topics (a)-(c) concern deficiencies in Common Lisp: The Language
that require resolution. Topics (d) and (e) are not addressed by
Common Lisp: The Language, but appear to be well-understood and
ready for standardization. Topics (f)-(i) concern areas where
standardization is desirable but not crucial to production of a
standard. Topic (j) is an area of current controversy within the
Lisp community. Other topics may be considered if specific
proposals are received.
4. The committee recognizes that Lisp programming practice will
continue to evolve and anticipates the need for future revisions
and extensions to the standard. This may include a family of
Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international
Lisp standard.
--------------------
End forwarded messages
∂20-Mar-87 1345 primerd!doug@enx.prime.pdn Windows and Graphics Subcommittee
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Mar 87 13:45:07 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <AA27326@EDDIE.MIT.EDU>; Fri, 20 Mar 87 16:45:27 EST
Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail)
id AA00379; Fri, 20 Mar 87 15:42:59 EST
Message-Id: <8703202042.AA00379@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 20 Mar 87 14:41:51 EST
Subject: Windows and Graphics Subcommittee
To: x3j13@sail.stanford.edu
From: primerd!DOUG@ENX.Prime.PDN
Date: 20 Mar 87 14:41:51 EST
I would like to make known that there is a mailing list for the
windows and graphics subgroup. To subscribe you can send mail
to me as dougr@eddie.mit.edu. The mailing list is
x3j13-windows@primerd.prime.com@eddie.mit.edu
Cheers,
Doug Rand
∂23-Mar-87 1130 berman@vaxa.isi.edu Gary Brown...
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 23 Mar 87 11:29:08 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA05051; Mon, 23 Mar 87 11:30:48 pst
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8703231930.AA05051@vaxa.isi.edu>
Date: 23 Mar 1987 1130-PST (Monday)
To: X3J13@SAIL
Cc:
Subject: Gary Brown...
I tried to send you mail at brown%bizet.DEC@decwrl.dec.com, but no luck, says
host not known. You got another address??
RB
∂20-Apr-87 0042 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET On the Kanji feature of Common Lisp
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 20 Apr 87 00:42:15 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa07982; 20 Apr 87 3:41 EDT
Received: from utokyo-relay by RELAY.CS.NET id ab14315; 20 Apr 87 3:34 AST
Received: from tansei.u-tokyo.junet by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA08435; Mon, 20 Apr 87 16:42:07 jst
Received: by tansei.u-tokyo.junet (4.12/6.2Junet)
id AA14916; Mon, 20 Apr 87 16:33:09+0900
Date: Mon, 20 Apr 87 16:33:09+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@ccut.u-tokyo.junet>
Message-Id: <8704200733.AA14916@tansei.u-tokyo.junet>
To: ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU,
x3j13@SAIL.STANFORD.EDU
Subject: On the Kanji feature of Common Lisp
Dear Bob Mathis,
Please suggest your idea on the contents of this mail.
Thank you.
Masayuki
--------------------------------------------------------
On 17th April, we had a meeting of Kanji WG under Jeida Common Lisp
Committee to discuss about the draft in ENGLISH for the kanji extension of Common Lisp.
We concluded that
1) we want to propose our specification to ANSI X3J13.
The specification is not so restrictive.
2) Prior to do so, One of the author, namely ida, will send
the whole contents to common-lisp@sail.stanford to get
reactions of the US colleagues.
3) The proposed date of submission to CL bboard is
on the week of May 11th.
4) We are ready to send a person to the next meeting
to explain our proposal.
5) The reactions on the CL bboard will be gathered, and will
be transfered to WG members as quick as possible.
(several of them have E-mail links to ida.)
We will try to discuss on the issue by E-mails as possible as we can.
(we have no ethernet-like link to USA, so we cannot reply immediately.)
we finished the first draft of the english version.
It was mainly translated by the person of Nippon Symbolics.
(Thanks Mr.Shiota.)
The size is 12 pages long in letter sized papers.
We will revise up and send it.
Masayuki Ida
∂20-Apr-87 2253 dcm%hpfclp@hplabs.HP.COM Fall X3J13 meeting
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87 22:53:25 PDT
Received: from hpfclp.HP.COM by hplabs.HP.COM with TCP ; Mon, 20 Apr 87 21:53:46 pst
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Mon, 20 Apr 87 23:52:41 mst
Received: by hpfcdcm.HP.COM; Mon, 20 Apr 87 22:53:41 mst
Date: Mon, 20 Apr 87 22:53:41 mst
From: Dave Matthews <dcm%hpfclp@hplabs.HP.COM>
Return-Path: <dcm@hpfcdcm>
Message-Id: <8704210553.AA03000@hpfcdcm.HP.COM>
To: +cl/x3j13@hplabs.HP.COM, x3j13@sail.stanford.edu
Subject: Fall X3J13 meeting
It probably seems a little early to start thinking about our fall meeting,
but I thought I would take an informal survey to help make the necessary
arrangements so we can confirm them at the summer meeting.
At the last X3J13 meeting, Susan Ennis volunteered to coordinate the
meeting schedule and I volunteered to host the fall meeting of X3J13
in colorful Colorado. We recently talked about the schedule for the
fall meeting and there seem to be a number of conferences that
time of year. We would like to pick a time convenient to as many
members as possible so I would like to conduct a survey.
Three months after the next meeting in late June would be late September
so I would nominally suggest September 28-30. Please fill out the
following table of available dates, listing the conflict if you believe
that others on the committee may have it also, such as OOPSLA.
Dates: MTWTF(y/n) Conflict?
------------- ----- ---------------------
Sep 21-Sep 25
Sep 28-Oct 2 yyyyy Example
Oct 5-Oct 9
Oct 12-Oct 16
Oct 19-Oct 23
Hopefully this range of dates will be sufficient for choosing 3 days.
I'll use this information to make preliminary arrangements and have a
proposal ready at the next meeting. Please return this by May 29.
Thanks,
Dave Matthews
dcm%hpfclp@hplabs.hp.com
∂21-Apr-87 0821 RWK@YUKON.SCRC.Symbolics.COM On the Kanji feature of Common Lisp
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87 08:21:20 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 195935; Tue 21-Apr-87 07:24:34 EDT
Date: Tue, 21 Apr 87 07:24 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: On the Kanji feature of Common Lisp
To: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
cc: ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU,
x3j13@SAIL.STANFORD.EDU
In-Reply-To: <8704200733.AA14916@tansei.u-tokyo.junet>
Message-ID: <870421072404.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Mon, 20 Apr 87 16:33:09+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
On 17th April, we had a meeting of Kanji WG under Jeida Common Lisp
Committee to discuss about the draft in ENGLISH for the kanji extension of Common Lisp.
We concluded that
1) we want to propose our specification to ANSI X3J13.
The specification is not so restrictive.
Professor Ida:
I believe it doesn't do it justice to describe this extension as a
"kanji extension". I have not yet seen an English translation of the
proposal, but from what I have seen of it, it appears to address much
wider concerns. I believe the concerns are quite relevant to any
implementation which deals with extended character-sets, or even which
try to make use of Common-Lisp's unfortunate "font" features.
From what I've been able to make of the proposal, it seems you are
on the right track, and I eagerly await your proposal.
∂23-Apr-87 0106 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET On the character-set extension of Common Lisp
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 23 Apr 87 01:06:01 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa13110; 23 Apr 87 4:02 EDT
Received: from utokyo-relay by RELAY.CS.NET id ab04744; 23 Apr 87 3:54 AST
Received: from tansei.u-tokyo.junet by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA27855; Thu, 23 Apr 87 16:04:19 jst
Received: by tansei.u-tokyo.junet (4.12/6.2Junet)
id AA04391; Thu, 23 Apr 87 15:55:22+0900
Date: Thu, 23 Apr 87 15:55:22+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@ccut.u-tokyo.junet>
Message-Id: <8704230655.AA04391@tansei.u-tokyo.junet>
To: RWK@SCRC-YUKON.ARPA, ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU,
x3j13@SAIL.STANFORD.EDU
Subject: On the character-set extension of Common Lisp
>Date: Tue, 21 Apr 87 07:24 EDT
>From: "Robert W. Kerns" <RWK@scrc-yukon.arpa>
>Subject: On the Kanji feature of Common Lisp
>To: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
>
> Date: Mon, 20 Apr 87 16:33:09+0900
> From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
> On 17th April, we had a meeting of Kanji WG under Jeida Common Lisp
> Committee to discuss about the draft in ENGLISH for the kanji extension of Common Lisp.
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
>
>Professor Ida:
>
>I believe it doesn't do it justice to describe this extension as a
>"kanji extension". I have not yet seen an English translation of the
>proposal, but from what I have seen of it, it appears to address much
>wider concerns. I believe the concerns are quite relevant to any
>implementation which deals with extended character-sets, or even which
>try to make use of Common-Lisp's unfortunate "font" features.
>
>>From what I've been able to make of the proposal, it seems you are
>on the right track, and I eagerly await your proposal.
>
>
Dear RWK,
you are right. I should have not described our conclusion on the extended
character-set manipulation as "kanji extension".
Though I myself told the WG on the Apr 17 meeting to update our document
to use the word "multi-byte character"
instead of "japanese character" or "kanji",
I myself missed to refer it as a "kanji" extension in my last mail.
Thank you
Masayuki Ida
∂15-May-87 0436 @MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM Next Meeting
Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 15 May 87 04:36:33 PDT
Received: from HAL.CAD.MCC.COM by MCC.COM with TCP; Fri 15 May 87 06:35:50-CDT
Date: Fri, 15 May 87 06:34 CDT
From: David D. Loeffler <Loeffler@MCC.COM>
Subject: Next Meeting
To: X3J13%sail.stanford.edu@MCC.COM
cc: Loeffler@MCC.COM
Message-ID: <870515063459.3.LOEFFLER@HAL.CAD.MCC.COM>
Reply-To: Loeffler@MCC.COM
Postal-address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759
Business-phone: (512) 338-3666
I have not seen any activity on this mailing list since the 23th of
April. What are the arrangements for the next meeting?
-- David D. Loeffler
∂31-May-87 0903 MATHIS@ADA20.ISI.EDU
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 31 May 87 09:03:19 PDT
Date: 31 May 1987 09:02-PDT
Sender: MATHIS@ADA20.ISI.EDU
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Cc: RWS@ZERMATT.LCS.MIT.EDU
Message-ID: <[ADA20.ISI.EDU]31-May-87 09:02:47.MATHIS>
A few words about the upcoming X3J13 meeting:
The meeting is being hosted by Goldhill Computers. Maria Santos
is making the arrangements. Their phone number is (617)
492-2071. They are reserving some rooms at the Cambridge Marriott
at a rate of $115 (plus tax) per night (insead of the more usual
$135). There will be some fee for refreshments and maybe a lunch.
I don't know what it will be, but at the last two meetings we
paid $25 or $50. The meeting will be on Tuesday June 30 and
Wednesday July 1. We will be meeting from about 9am to 5pm each
day. There may be some subcommittee meetings on Monday. They are
hoping to arrange some meeting rooms at MIT, but I don't know the
specifics yet. Hope you can all make it.
I was thinking about the following agenda:
Tuesday morning -- clean-up committee
Tuesday afternoon -- X windows presentation, Japanese
characters presentation, administrative work of committee,
reports from various subcommittees and liaisons
Wednesday morning -- continuation of subcommittee reports
and other business, clean-up committee
Wednesday afternoon -- clean-up committee
We picked Tuesday and Wednesday for the main meeting so we could
use Monday for subcommittees if needed.
The X windows presentation will be by Robert Scheifler. We are
not looking at this for incorporation into the Common Lisp
standard, but as an important and relevant related application.
CLX is a proposed interface to the X Version 11 Window System
Protocol. It is intended as fairly low-level veneer, to hide
mundane details such as data encodings, network I/O, and even the
existance of an explicit inter-process communication channel.
The intent is to provide direct access to features of the
protocol, but with an effective Lisp orientation, and with
consideration given to convenience of use. A goal was to permit
efficient implementations on both conventional and Lisp-specific
architectures, and to provide reasonable semantics in both
single-process and multi-process environments. The expectation
and desire is that this X-specific interface will be wrapped by
more generic and higher-level windowing and graphics interfaces,
suitable for general application programming. However, we did
not wish to preclude an X-specific, object-oriented system built
directly on this interface. A public implementation of this
interface is underway, to serve as a mechanism for evaluating the
interface.
I am sending five relatively long messages which I recieved from
Scheifler which give the protocol and the Lisp code.
The Japanese characters proposal was sent to the general Common
Lisp mailing list. I am retransmitting it for your reference.
The cleanup committee has been hard at work and they will shortly
be sending their documents. So read what I'm sending now and save
it some place because more is coming.
-- Bob
∂31-May-87 0915 MATHIS@ADA20.ISI.EDU A multi-byte character extension proposal
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 31 May 87 09:14:47 PDT
Return-Path: <@USC-ECLB.ARPA,@SAIL.STANFORD.EDU,@RELAY.CS.NET:a37078%tansei.u-tokyo.junet@UTOKYO-RELAY.CSNET>
Date: Mon, 18 May 87 14:06:46+0900
From: Masayuki Ida <a37078%tansei.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@tansei.cc.u-tokyo.junet>
Message-Id: <8705180506.AA06726@tansei.cc.u-tokyo.junet>
To: common-lisp@SAIL.STANFORD.EDU, ida%tansei.u-tokyo.junet@RELAY.CS.NET
Subject: A multi-byte character extension proposal
ReSent-To: x3j13@SAIL.STANFORD.EDU
ReSent-From: MATHIS at ADA20.ISI.EDU
ReSent-Date: 31 May 1987
Date: Mon, 18 May 87 09:44:19 JST
From: moto@XXX.XXX.junet (MOTOYOSHI)
To: ida@tansei.cc.u-tokyo.junet
Subject: Kanji Proposal
-------------------- Beginning of text --------------------
@Comment[-*- Mode: Text -*-]
@heading[Digest]
@heading[1. Hierarcy of characters and strings]
Let the value of char-code-limit be large enough to include all
characters.
char > string-char >= internal-string-char > standard-char
string >= internal-thin-string > simple-internal-thin-string
simple-string >= simple-internal-thin-string
string = (or internal-thin-string (vector string-char))
Type internal-thin-string and (vector string-char) are
disjoint or identical.
simple-string = (or simple-internal-thin-string
(simple-array string-char (*)))
Type simple-internal-thin-string and (simple-array
string-char (*)) are disjoint or identical.
notes: A > B means B is a subtype of A,
A >= B means B is a subtype of A or B is equal to A.
@Heading[2. Print width]
Only standard characters are required to have fix-pitched
print width. Use the newly introdued function 'write-width'
to know the print width of an expression.
@Heading[3. Functions]
Functions dealing with strings should work as before,
expect ones which change the contents of internal-thin-string
to non internal-thin-char's.
Functions producing strings should create (vector
string-char), not internal-thin-string, unless they were
explicitly specified.
Funtions comaring strings should copare them elementwise.
Therefore it is possible that a (vector string-char) is equal
to an internal-thin-string.
@newpage
@Heading[1. A proposal for embedding multi-byte characters]
The Kanji Working Group (KWG) examined implementation of facilities for
multi-byte character to Common Lisp. This report is the result of many
discussions of many proposals. Of course, this report doesn't satisfy
all proposals, but it is very close.
In order to decide on a final proposal, we chose essential and
desirable characteristics of a working multi-byte character system.
Chapter 2 describes these characteristics in some detail.
Chapter 3 describes additional features to Common Lisp which will be useful
not just for multi-byte character, but also for many other kinds of character sets.
This chapter describes internal data structures. If this proposal is
accepted in Common Lisp, it will be easy for countries to add original mechanisms.
Chapters 4 describes proposed changes to @I[Common Lisp -- The Language]
(CLtL).
@Heading[2. Additional features for embedding multi-byte characters.]
This chapter describes design principles which can be used to design
multi-byte character language extensions to Common Lisp.
There are many programming languages which can multi-byte characters.
Most of them can use multi-byte character as string character data
but not as variables or function names.
It is necessary for programming languages like Lisp that use symbolic data
to be able to process not only single-byte characters but also multi-byte characters.
That is, it should be possible to use multi-byte characters in character string and
symbols, and it must be possible to store both kinds of characters in them.
Treating multi-byte characters just like other alpha-numeric characters
means that multi-byte character must be treated as a single character object.
Many of the present implementations of Lisp treat multi-byte character as
pairs of bytes. Alternatively, they use a different data type which
doesn't permit multi-byte character to be mixed with standard characters.
Such systems are not useful for user.
Thus, the basic design principles for embedding multi-byte character to Common Lisp are:
@Begin[Itemize]
Multi-byte character should be treated like single-byte character, that is,
a multi-byte character is one character object.
@End[Itemize]
@Begin[Itemize]
A program which was coded without explicit attention for multi-byte character should
handle multi-byte character data as is.
@End[Itemize]
These principles provide sufficient functionality, but we can't ignore
efficiency. So we considered the next principle:
@Begin[Itemize]
The performance of the system in terms of CPU and memory
utilization should not be consideraly affected in programs which do not use multi-byte
characters.
@End[Itemize]
This principle is contradictory to other principles, but this can't be
ignored when we consider the users of actual systems, so we have to
compromise. We think that following methods will satisfy both of these
requirements.
@Heading[3. Common parts which we implement.]
This chapter describes the implementation of multiple character sets in Common Lisp.
To treat multi-byte characters like single-byte characters, the multi-byte character must be
included in the set of possible character codes.
We consider the following implementation methods.
@Begin[Itemize]
Add multi-byte characters by setting the variable char-code-limit to a large number.
@End[Itemize]
In this case, the single-byte character set and the multi-byte character
set must be ordered into a single sequence of character codes. This means multi-byte
character set must not overlap with the single-byte character set. This method could
be satisfied within most implementations with ease.
If we use this method, it is possible to use multi-byte characters with
fonts in Common Lisp, and operations that work for single-byte
character will also work for multi-byte character without any change.
This implementation method has problems with efficiency.
In the case that the value of character code is greater than size of 1 byte
(multi-byte characters are in this category), memory utilization is
affected. A string containing only one single-byte character is 2 bytes long.
The same problem would also occur with symbol p-names. If we can solve the problem
for strings, we can solve other problems, so we will start by considering only strings.
To avoid this memory utilization problem, it is possible to optimize and
make single-byte character strings by packing internally. In other words,
to have two kinds of data types and not show it to user. There is only one type of
data from the viewpoint of users, which means that every function which uses strings
will continue to work as defined.
This can be implemented in almost everywhere without so many costs. The only
problem occurs when a function attempts to put a multi-byte character into an optimized
and packed sigle-byte-only string. To work according to the definition, the implementation
must unpack the original packed string. This presents an implementation inefficiency which
the user may find undesirable.
One solution would be to
@Begin[Itemize]
Generate errors for operations that try to use multi-byte characters into
single-byte string and presenting two string datatypes to users.
@End[Itemize]
We propose this latter implementation. Common lisp should have 2 string
types to treat multi-byte characters efficiently. The first of these is
@b[ε1stringε0], which stores any character of type @B[ε1string-charε0], i.e.,
whose @I[ε2bitsε0] and @I[ε2fontε0] are both zero. The type of string is
@B[ε1internal-thin-stringε0] which is the optimized character string.
@B[ε1internal-thin-charε0] is a subtype of @B[ε1characterε0] and can be inserted into string
@B[ε1internal-thin-stringε0]. The predicate which tests for this type of character is
@B[ε1internal-thin-char-pε0].
The type @B[ε1internal-thin-charε0] is a subtype of @B[ε1string-charε0], and is a
supertype of @B[ε1standard-charε0].
The data type hierarchy for @B[ε1characterε0] and @B[ε1stringε0] is shown in figure 1.
@b[ε1Internal-thin-charε0] and @b[ε1string-charε0] may be equal as it is possible that situations
may arise where both sets describe the same character-set.
This is equivalent to the type of system that has only one type of character from the
viewpoint of the user as discussed in the previous chapter. This proposal permits both
kinds of implementations.
@newpage
@Begin[Verbatim]
character
|
string-char
|
internal-thin-char
|
standard-char
@Center[Fig-1.a Structure of character type]
string
|
-----------------------------------
| | |
| simple-string |
| | |
internal-thin-string | (vector string-char)
| | |
-----------------------------------
| |
| |
simple-internal-thin-string (simple-array string-char (*))
@Center[Fig-1.b Structure of string type]
@End[Verbatim]
To compare @B[ε1stringε0] characters with @B[ε1internal-thin-stringε0] characters, it is
necessary to convert both to the @B[ε1string-charε0] format. This means that
the same character is the same object regardless of whether it is found
in an @B[ε1internal-thin-stringε0] or a normal @B[ε1stringε0].
Next we must discuss character input. The proposal does not discuss what is stored
in files, nor what happens between the Lispimplementation and a terminal.
Each system will implement this in itsown way. Instead, let us discuss the data
as passed to lisp programs. We think that treating all input data as @B[ε1stringε0]
is the safest possible course. Since a symbol's p-name string should not be modified,
it can be optimized.
This may cause performance problems for programs which use only
single-byte characters. The variable @B[ε1*read-default-string-type*ε0] is
provided for these programs. When its value is @B[ε1internal-thin-stringε0], the system
expects single-byte characters only. so the system will return input data
in the form of @B[ε1internal-thin-stringε0]. Though it is possible that the system may
choose to ignore this variable.
@newpage
@Heading[4 Proposed changes to CLtL to support multiple character sets.]
In this section, we list proposed modifications to CLtL. Chapters 13,
14 and 18 of CLtL are concerned very greatly with multi-byte character, so we specify
modifications to these chapters by making a list of all constants,
functions and variables. For other chapters we specify only additional
and modifying parts. Those portions which are not mentioned are
unchanged.
@b(2 Data Types)
@b(2.5.2 Strings)
@begin(equation)
"a string is a specialized vector .... type string-char"
↓
"a string is a specialized vector .... type string-char or @B[internal-thin-char]"
@end(equation)
@b(2.15 Overlap,Inclusion and Disjointness of Types)
a description of type string-char is changed to :
Type standard-char is a subtype of @B[internal-thin-char].
@B[internal-thin-char] is a subtype of string-char. string-char is a
subtype of character.
and add the following :
Type @B[internal-thin-string] is a subtype of vector because @B[internal-thin-string] means
(vector internal-thin-char).
a description of type string is changed to :
Type string is a subtype of vector because string means (or
(vector string-char) internal-thin-string). Type (vector
string-char) and @B[internal-thin-string] are disjoint or equality.
a description of type simple-vector,simple-string ... is changed to :
Type simple-vector,simple-string and simple-bit-vector are disjoint subtype of
simple-array because each one means (simple-array t (*)),
(or (simple-array string-char (*)),(or (simple-array internal-thin-char (*)) and
(simple-array bit (*)).
and add following :
Type simple-internal-thin-string means (simple-array
internal-thin-char (*)) and is a subtype of @B[internal-thin-string].
Type (simple-array string-char (*)) and simple-internal-thin-string are disjoint or
equality.
@b(4 Type Specifiers)
@b(4.1 Type Specifier Symbols)
add followings to system defined type specifiers :
simple-internal-thin-string
internal-thin-string
internal-thin-char
@b(4.5 Type Specifiers That Specialize)
"The specialized types (vector string-char) ... data types."
↓
"The specialized types (vector internal-thin-char), (vector
string-char) and (vector bit) are so useful that they have the
special names string and bit-vector. Every implementation of Common
Lisp must provide distinct representation for string and bit-vector
as distinct specialized data types."
@begin(equation)
@b(13 Characters)
@b(13.1 Character Attributes)
char-code-limit@>[constant]
char-font-limit@>[constant]
char-bits-limit@>[constant]
@b(13.2 Predicates on Characters)
standard-char-p char@>[constant]
graphic-char-p char@>[constant]
@begin(quotation)
a description "graphic characters of font 0 are all of the same width when printed" in
the CLtL changed to "standard-char without #\Newline of font 0 are all of the same
width when printed".
@end(quotation)
string-char-p char @>[function]
internal-thin-char-p char@>[function]
@begin(quotation)
this function must be added.
the argument char must be a character object. internal-thin-char-p
is true if char can be stored into a internal-thin-string, and
otherwise is false.
@end(quotation)
alpha-char-p char@>[function]
upper-case-p char@>[function]
lower-case-p char@>[function]
both-case-p char@>[function]
"If a character is either ... alphabetic."
↓
"If a character is either uppercase or lowercase, it is necessarily character
that alpha-char-p returns true."
digit-char-p char &optional (radix 10)@>[function]
alphanumericp char@>[function]
char= character &rest more-characters@>[function]
char/= character &rest more-characters@>[function]
char< character &rest more-characters@>[function]
char> character &rest more-characters@>[function]
char<= character &rest more-characters@>[function]
char>= character &rest more-characters@>[function]
char-equal character &rest more-characters@>[function]
char-not-equal character &rest more-characters@>[function]
char-lessp character &rest more-characters@>[function]
char-greaterp character &rest more-characters@>[function]
char-not-greaterp character &rest more-characters@>[function]
char-not-lessp character &rest more-characters@>[function]
@b(13.3 Character Construction and Selection)
char-code char@>[function]
char-bits char@>[function]
char-font char@>[function]
code-char char &optional (bits 0) (font 0)@>[function]
make-char char &optional (bits 0) (font 0)@>[function]
@b(13.4 Character Conversion)
character char@>[function]
char-upcase char@>[function]
char-downcase char@>[function]
digit-char weight &optional (radix 10) (font 0)@>[function]
char-int char@>[function]
int-char char@>[function]
char-name char@>[function]
name-char char@>[function]
@b(13.5 Character control-bit functions)
char-control-bit@>[constant]
char-meta-bit@>[constant]
char-super-bit@>[constant]
char-hyper-bit@>[constant]
char-bit char name@>[function]
set-char-bit char name newvalue@>[function]
@b(14 Sequence)
@b(14.1 Simple sequence functions)
elt sequence index@>[Function]
subseq sequence start &optional end@>[Function]
copy-seq sequence@>[Function]
length sequence@>[Function]
reverse sequence@>[Function]
nreverse sequence@>[Function]
make-sequence type size &key :initial-element@>[Function]
@b(14.2 Sequence connection)
concatenate result-type &rest sequences@>[Function]
map result-type function sequence &rest more-sequences@>[Function]
some predicate sequence &rest more-sequences@>[Function]
every predicate sequence &rest more-sequences@>[Function]
notany predicate sequence &rest more-sequences@>[Function]
notevery predicate sequence &rest more-sequences@>[Function]
reduce function sequence@>[Function]
&key :from-end :start :end :initial-value
@b(14.3 Sequence correction)
fill sequence item &key :start :end@>[Function]
replace sequence1 sequence2 &key :start1 :end1 :start2 :end2@>[Function]
remove item sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
remove-if test sequence@>[Function]
&key :from-end :start
:end :count :key
remove-if-not test sequence@>[Function]
&key :from-end :start
:end :count :key
delete item sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
remove-if test sequence@>[Function]
&key :from-end :start
:end :count :key
remove-if-not test sequence@>[Function]
&key :from-end :start
:end :count :key
remove-duplicates sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
delete-duplicates sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
subsutitute newitem test sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
subsutitute-if newitem test sequence@>[Function]
&key :from-end :start :end :count :key
subsutitute-if-not newitem test sequence@>[Function]
&key :from-end :start :end :count :key
nsubsutitute newitem test sequence@>[Function]
&key :from-end :test :test-not
:start :end :count :key
nsubsutitute-if newitem test sequence@>[Function]
&key :from-end :start :end :count :key
nsubsutitute-if-not newitem test sequence@>[Function]
&key :from-end :start :end :count :key
@b(14.4 Search)
find item sequence @>[Function]
&key :from-end :test :test-not
:start :end :key
find-if test sequence @>[Function]
&key :from-end :start :end :key
find-if-not test sequence>[Function]
&key :from-end :start :end :key
position item sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
position-if test sequence@>[Function]
&key :from-end :start :end :key
position-if-not test sequence@>[Function]
&key :from-end :start :end :key
count item sequence@>[Function]
&key :from-end :test :test-not
:start :end :key
count-if item sequence@>[Function]
&key :from-end :start :end :key
count-if-not item sequence@>[Function]
&key :from-end :start :end :key
mismatch sequence1 sequence2@>[Function]
&key :from-end :test :test-not
:key :start1 :start2
:end1 :end2
search sequence1 sequence2@>[Function]
&key :from-end :test :test-not
:key :start1 :start2
:end1 :end2
@b(14.5 Sort,merge)
sort sequence predicate &key :key@>[Function]
stable-sort sequence predicate &key :key@>[Function]
merge result-type sequence1 sequence2 predicate &key :key@>[Function]
@b(18 Strings)
"the type string is identical ... (array string-char (*))."
↓
"the type string is identical to the type
(or (vector internal-thin-char) (vector string-char)),
which in turn is the same as (or (array internal-thin-char (*))
(array string-char (*)))."
@b(18.3 String Construction and Manipulation)
make-string size &key :initial-element@>[function]
@begin(quotation)
add following :
To make an internal-thin-string, you should use make-array or make-sequence.
@end(quotation)
@b(22 Input/Output)
@b(22.2 Input Functions)
@b(22.2.1 Output to Character Stream)
add following :
*read-default-string-type*@>[variables]
@begin(quotation)
The value is string or internal-thin-string. This determines string that the function
read takes whether type string or internal-thin-string.
@end(quotation)
@b(22.3 Output Functions)
@b(22.3.1 Output from Character Stream)
@begin(quotation)
add following :
@end(quotation)
write-width object@>[function]
&key :unit-type :stream :escape :radix :base
:circle :pretty :label :length :case :gensym :array
@begin(quotation)
This function returns the printed width as the value of the unit
specified by :unit-type when then printed representation of
object is written to the output stream specified by :stream. It
returns nil when object includes control characters
(#\Newline,#\Tab etc). The default of :unit-type is byte. The
value which we can specify :unit-type depends on implementation.
@end(quotation)
@end(equation)
@newpage
@Heading[Appendix Proposed Japanese character processing facilities for Common Lisp.]
In addition to the modification of CLtL, here are some suggestions for systems
including Japanese characters.
1). How should system behave for Japanese characters both
under unmodified part of CLtL and the part changed for multi-byte
processing.
2). About function that are specific to Japanese and no at all related
to multi-byte processing.
Notes: All Japanese characters are constituent. JIS is a abreviation of Japanese Industry
Standard.
@begin(equation)
@b(13. Characters)
@b(13.1. Character Attributes)
char-code-limit char @>[Function]
@begin(quotation)
The value of char-code-limit should be large enough to include Japanese characters,
e.g. 65536.
@end(quotation)
@b(13.2. Predicates on Characters)
standard-char-p char @>[Function]
@begin(quotation)
Return nil for all Japanese characters.
@end(quotation)
graphic-char-p char @>[Function]
@begin(quotation)
Return t for Japanese characters.
@end(quotation)
internal-thin-char-p char @>[Function]
@begin(quotation)
The result depends on each implementation that whether the Japanese character is in
internal-thin-string or not.
@end(quotation)
alpha-char-p char @>[Function]
@begin(quotation)
Return nil for all character except alphabets in Japanese character. It depends on
each implementation whether to return t or nil for alphabets in Japanese characters.
@end(quotation)
@newpage
jis-char-p char@>[Function]
@begin(quotation)
The argument char has to be a character type object. jis-char-p is true if the
argument is included in JIS C-6226, and otherwise false.
@end(quotation)
japanese-char-p char@>[Function]
@begin(quotation)
The argument char has to be a character type object. japanese-char-p is true if the
argument is a Japanese character and is otherwise false. All characters that satisfy
jis-char-p must satisfy japanese-char-p; other characters might.
@end(quotation)
kanji-char-p char@>[Function]
@begin(quotation)
The argument char has to be character type object. kanji-char-p is true if the
argument is one of the 6353 Kanji characters in JIS C6226(3.1.8), the repeat symbol,
the kanji numeric zero or the same as above symbol for a total of 6356 characters
that also satisfy jis-char-p.
@end(quotation)
hiragana-char-p char@>[Function]
@begin(quotation)
The argument char has to be character type object.
hiragana-char-p is true if the argument is one of the 83
hiragana characters in JIS C6226(3.1.4), the hiragana repeat
symbol, or dakuten for a total of 85 characters that also
satisfy jis-char-p.
@end(quotation)
katakana-char-p char@>[Function]
@begin(quotation)
The argument char has to be a character type object.
katakana-char-p is true if the argument is one of the 86
hiragana characters in JIS C6226(3.1.5), long-sound-symbol,
katakana-repeat symbol, or katakana-dakuten for a total of 89
characters that also satisfy jis-char-p.
@end(quotation)
kana-char-p char@>[Function]
@begin(quotation)
equivalence (or (hiragana-char-p char) (katakana-char-p char))
@end(quotation)
upper-case-p char@>[Function]
lower-case-p char@>[Function]
both-case-p char@>[Function]
@begin(quotation)
These are nil if the argument does not satisfy alpha-char-p.
Japanese characters which satisfy alpha-char-p should be treated
as normal alphabetic characters.
@end(quotation)
@newpage
digit-char-p char &optional (radix 10)@>[Function]
@begin(quotation)
digit-char-p is nil if the argument is a Japanese character.
@end(quotation)
alphanumericp char@>[Function]
@begin(quotation)
equivalence (or (alpha-char-p char) (not (null (digit-char-p char))))
@end(quotation)
char= character &rest more-characters@>[Function]
char/= character &rest more-characters@>[Function]
char< character &rest more-characters@>[Function]
char> character &rest more-characters@>[Function]
char<= character &rest more-characters@>[Function]
char>= character &rest more-characters@>[Function]
@begin(quotation)
The ordering of hiragana, katakana, kanji follows the JIS ordering.
@end(quotation)
@b(13.4 character Conversions)
char-upcase char@>[Function]
char-downcast char@>[Function]
@begin(quotation)
These return the argument if the argument does not satisfy
alpha-char-p. It depends on the implementation whether these
work on the alphabets included in JIS or not. But it should be
consistent with upper-case-p, lower-case-p, both-case-p.
@end(quotation)
@end(equation)
∂31-May-87 0914 MATHIS@ADA20.ISI.EDU CLX part 1 of 2
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 31 May 87 09:13:44 PDT
Return-Path: <RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU>
Date: Sat, 30 May 87 09:56 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX part 1 of 2
To: MATHIS@ADA20.ISI.EDU
Message-ID: <870530095642.5.RWS@KILLINGTON.LCS.MIT.EDU>
ReSent-To: x3j13@SAIL.STANFORD.EDU
ReSent-From: MATHIS at ADA20.ISI.EDU
ReSent-Date: 31 May 1987
;;; -*- Mode: LISP; Syntax: Common-lisp; Package: (XLIB (CL)); Base: 10; Lowercase: Yes -*-
;; Draft Version 3.1 (corresponds to Alpha Update protocol document)
;; Author:
;; Robert W. Scheifler
;; Laboratory for Computer Science
;; 545 Technology Square, Room 418
;; Cambridge, MA 02139
;; rws@zermatt.lcs.mit.edu
;; Contributors:
;; Dan Cerys, Texas Instruments
;; Scott Fahlman, CMU
;; Kerry Kimbrough, Texas Instruments
;; Chris Lindblad, MIT
;; Rob MacLachlan, CMU
;; Mike McMahon, Symbolics
;; David Moon, Symbolics
;; LaMott Oren, Texas Instruments
;; Daniel Weinreb, Symbolics
;; John Wroclawski, MIT
;; Richard Zippel, Symbolics
;; Note: all of the following is in the package XLIB.
;; Note: various perversions of the CL type system are used below.
;; Examples: (list elt-type) (sequence elt-type)
(proclaim '(declaration arglist values))
;; Note: if you have read the Version 11 protocol document or C Xlib manual, most of
;; the relationships should be fairly obvious. We have no intention of writing yet
;; another moby document for this interface.
;; Types employed: display, window, pixmap, cursor, font, gcontext, colormap, color.
;; These types are defined solely by a functional interface; we do not specify
;; whether they are implemented as structures or flavors or ... Although functions
;; below are written using DEFUN, this is not an implementation requirement (although
;; it is a requirement that they be functions as opposed to macros or special forms).
;; It is unclear whether with-slots in the Common Lisp Object System must work on
;; them.
;; Windows, pixmaps, cursors, fonts, gcontexts, and colormaps are all represented as
;; compound objects, rather than as integer resource-ids. This allows applications
;; to deal with multiple displays without having an explicit display argument in the
;; most common functions. Every function uses the display object indicated by the
;; first argument that is or contains a display; it is an error if arguments contain
;; different displays, and predictable results are not guaranteed.
;; Each of window, pixmap, cursor, font, gcontext, and colormap have the following
;; five functions:
(defun make-<mumble> (display resource-id)
;; This function should almost never be called by applications, except in handling
;; events. To minimize consing in some implementations, this may use a cache in
;; the display. Make-gcontext creates with :cache-p nil. Make-font creates with
;; cache-p true.
(declare (type display display)
(type integer resource-id)
(values <mumble>)))
(defun <mumble>-display (<mumble>)
(declare (type <mumble> <mumble>)
(values display)))
(defun <mumble>-id (<mumble>)
(declare (type <mumble> <mumble>)
(values integer)))
(defun <mumble>-equal (<mumble>-1 <mumble>-2)
(declare (type <mumble> <mumble>-1 <mumble>-2)))
(defun <mumble>-p (<mumble>-1 <mumble>-2)
(declare (type <mumble> <mumble>-1 <mumble>-2)
(values boolean)))
;; The following functions are provided by color objects:
;; The intention is that IHS and YIQ and CYM interfaces will also exist. Note that
;; we are explicitly using a different spectrum representation than what is actually
;; transmitted in the protocol.
(defun make-color (&key red green blue &allow-other-keys) ; for expansion
(declare (type (number 0 1) red green blue)
(values color)))
(defun color-rgb (color)
(declare (type color color)
(values red green blue)))
(defun color-red (color)
;; setf'able
(declare (type color color)
(values (number 0 1))))
(defun color-green (color)
;; setf'able
(declare (type color color)
(values (number 0 1))))
(defun color-blue (color)
;; setf'able
(declare (type color color)
(values (number 0 1))))
(deftype resource-id () 'integer)
(deftype drawable () '(or window pixmap))
;; Atoms are accepted as strings or symbols, and are always returned as keywords.
;; Protocol-level integer atom ids are hidden, using a cache in the display object.
(deftype xatom () '(or string symbol))
(deftype stringable () '(or string symbol))
(deftype fontable () '(or stringable font))
;; Nil stands for CurrentTime.
(deftype timestamp () '(or null integer))
(deftype bit-gravity () '(member :forget :static :north-west :north :north-east
:west :center :east :south-west :south :south-east))
(deftype win-gravity () '(member :unmap :static :north-west :north :north-east
:west :center :east :south-west :south :south-east))
(deftype grab-status ()
'(member :success :already-grabbed :frozen :invalid-time :not-viewable))
(deftype boolean () '(or null (not null)))
;; An association list.
(deftype alist (key-type-and-name datum-type-and-name) 'list)
;; A sequence, containing zero or more repetitions of the given elements,
;; with the elements expressed as (type name).
(deftype repeat-seq (&rest elts) 'sequence)
(deftype point-seq () '(repeat-seq (integer x) (integer y)))
(deftype seg-seq () '(repeat-seq (integer x1) (integer y1) (integer x2) (integer y2)))
(deftype rect-seq () '(repeat-seq (integer x) (integer y) (integer width) (integer height)))
;; Note that we are explicitly using a different angle representation than what
;; is actually transmitted in the protocol.
(deftype angle () `(number ,(* -2 pi) ,(* 2 pi)))
(deftype arc-seq () '(repeat-seq (integer x) (integer y) (integer width) (integer height)
(angle angle1) (angle angle2)))
(deftype event-mask-class ()
'(member :key-press :key-release :owner-grab-button :button-press :button-release
:enter-window :leave-window :pointer-motion :pointer-motion-hint
:button-1-motion :button-2-motion :button-3-motion :button-4-motion
:button-5-motion :button-motion :exposure :visibility-change
:structure-notify :resize-redirect :substructure-notify :substructure-redirect
:focus-change :property-change :colormap-change :keymap-state))
(deftype event-mask ()
'(or integer (list event-mask-class)))
(deftype pointer-event-mask-class ()
'(member :button-press :button-release
:enter-window :leave-window :pointer-motion :pointer-motion-hint
:button-1-motion :button-2-motion :button-3-motion :button-4-motion
:button-5-motion :button-motion :keymap-state))
(deftype pointer-event-mask ()
'(or integer (list pointer-event-mask-class)))
(deftype device-event-mask-class ()
'(member :key-press :key-release :button-press :button-release :pointer-motion
:button-1-motion :button-2-motion :button-3-motion :button-4-motion
:button-5-motion :button-motion))
(deftype device-event-mask ()
'(or integer (list device-event-mask-class)))
(deftype modifier-key ()
'(member :shift :caps-lock :control :mod-1 :mod-2 :mod-3 :mod-4 :mod-5))
(deftype modifier-mask ()
'(or (member :any) integer (list modifier-key)))
(deftype state-mask-key ()
'(or modifier-key (member :button-1 :button-2 :button-3 :button-4 :button-5)))
(deftype gcontext-key ()
'(member :function :plane-mask :foreground :background
:line-width :line-style :cap-style :join-style :fill-style :fill-rule
:arc-mode :tile :stipple :ts-x :ts-y :font :subwindow-mode
:exposures :clip-x :clip-y :clip-mask :clip-ordering
:dash-offset :dashes))
(deftype event-key ()
'(member :key-press :key-release :button-press :button-release :motion-notify
:enter-notify :leave-notify :focus-in :focus-out :keymap-notify
:exposure :graphics-exposure :no-exposure :visibility-notify
:create-notify :destroy-notify :unmap-notify :map-notify :map-request
:reparent-notify :configure-notify :gravity-notify :resize-request
:configure-request :circulate-notify :circulate-request :property-notify
:selection-clear :selection-request :selection-notify
:colormap-notify :client-message))
(deftype error-key ()
'(member :access :alloc :atom :colormap :cursor :drawable :font :gcontext :id-choice
:illegal-request :implementation :length :match :name :pixmap :property
:value :window))
(deftype draw-direction ()
'(member :left-to-right :right-to-left))
(defstruct bitmap-format
(unit <unspec> :type (member 8 16 32))
(pad <unspec> :type (member 8 16 32))
(lsb-first-p <unspec> :type boolean))
(defstruct pixmap-format
(depth <unspec> :type integer)
(bits-per-pixel <unspec> :type (member 4 8 16 32))
(pad <unspec> :type (member 8 16 32)))
(defstruct visual-info
(id <unspec> :type integer)
(class <unspec> :type (member :static-gray :static-color :true-color
:gray-scale :pseudo-color :direct-color))
(red-mask <unspec> :type integer)
(green-mask <unspec> :type integer)
(blue-mask <unspec> :type integer)
(bits-per-rgb <unspec> :type integer)
(colormap-entries <unspec> :type integer))
(defstruct screen
(root <unspec> :type window)
(device <unspec> :type integer)
(width <unspec> :type integer)
(height <unspec> :type integer)
(width-in-millimeters <unspec> :type integer)
(height-in-millimeters <unspec> :type integer)
(depths <unspec> :type (alist (integer depth) ((list visual-info) visuals)))
(root-depth <unspec> :type integer)
(root-visual <unspec> :type integer)
(default-colormap <unspec> :type colormap)
(white-pixel <unspec> :type integer)
(black-pixel <unspec> :type integer)
(min-installed-maps <unspec> :type integer)
(max-installed-maps <unspec> :type integer)
(backing-stores <unspec> :type (member :never :when-mapped :always))
(save-unders-p <unspec> :type boolean)
(event-mask-at-open <unspec> :type integer))
;; To allow efficient storage representations, the type char-info is not
;; required to be a structure.
(defun char-left-bearing (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-right-bearing (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-width (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-ascent (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-descent (char-info)
(declare (type char-info char-info)
(values integer)))
(defun char-attributes (char-info)
(declare (type char-info char-info)
(values integer)))
;; The list contains alternating keywords and integers.
(deftype font-props () 'list)
(defstruct font-info
(name <unspec> :type string)
(direction <unspec> :type draw-direction)
(min-char <unspec> :type integer)
(max-char <unspec> :type integer)
(min-byte1 <unspec> :type integer)
(max-byte1 <unspec> :type integer)
(min-byte2 <unspec> :type integer)
(max-byte2 <unspec> :type integer)
(all-chars-exist-p <unspec> :type boolean)
(default-char <unspec> :type integer)
(min-bounds <unspec> :type char-info)
(max-bounds <unspec> :type char-info)
(ascent <unspec> :type integer)
(descent <unspec> :type integer)
(properties <unspec> :type font-props))
(defun open-display (host &key (display 0) protocol)
;; A string must be acceptable as a host, but otherwise the possible types for host
;; and protocol are not constrained, and will likely be very system dependent. The
;; default protocol is system specific. Authorization, if any, is assumed to come
;; from the environment somehow.
(declare (type integer display)
(values display)))
(defun display-protocol-version (display)
;; Values are integers.
(declare (type display display)
(values major minor)))
(defun display-vendor (display)
;; Values are string and integer
(declare (type display display)
(values name release)))
(defun display-image-lsb-first-p (display)
(declare (type display display)
(values boolean)))
(defun display-bitmap-formap (display)
(declare (type display display)
(values bitmap-format)))
(defun display-pixmap-formats (display)
(declare (type display display)
(values (list pixmap-formats))))
(defun display-roots (display)
(declare (type display display)
(values (list screen))))
(defun display-keyboard (display)
(declare (type display display)
(values integer)))
(defun display-pointer (display)
(declare (type display display)
(values integer)))
(defun display-motion-buffer-size (display)
(declare (type display display)
(values integer)))
(defun display-max-request-length (display)
(declare (type display display)
(values integer)))
(defun close-display (display)
(declare (type display display)))
(defun display-error-handler (display)
(declare (type display display)
(values handler)))
(defsetf display-error-handler (display) (handler)
;; All errors (synchronous and asynchronous) are processed by calling an error
;; handler in the display. If handler is a sequence it is expected to contain
;; handler functions specific to each error; the error code is used to index the
;; sequence, fetching the appropriate handler. Any results returned by the handler
;; are ignored; it is assumed the handler either takes care of the error
;; completely, or else signals. For all core errors, the keyword/value argument
;; pairs are:
;; :display display
;; :error-key error-key
;; :major integer
;; :minor integer
;; :sequence integer
;; :current-sequence integer
;; For :colormap, :cursor, :drawable, :font, :gcontext, :id-choice, :pixmap, and
;; :window errors another pair is:
;; :resource-id integer
;; For :atom errors, another pair is:
;; :atom-id integer
;; For :value errors, another pair is:
;; :value integer
(declare (type display display)
(type (or (sequence (function (&rest key-vals)))
(function (&rest key-vals)))
handler)))
(defmacro define-condition (name base &body items)
;; just a place-holder here for the real thing
)
(define-condition request-error error
display
major
minor
sequence
current-sequence)
(defun default-error-handler (&rest key-vals)
;; The default display-error-handler.
;; It signals the conditions listed below.
)
(define-condition resource-error request-error
resource-id)
(define-condition access-error request-error)
(define-condition alloc-error request-error)
(define-condition atom-error request-error
atom-id)
(define-condition colormap-error resource-error)
(define-condition cursor-error resource-error)
(define-condition drawable-error resource-error)
(define-condition font-error resource-error)
(define-condition gcontext-error resource-error)
(define-condition id-choice-error resource-error)
(define-condition illegal-request-error request-error)
(define-condition implementation-error request-error)
(define-condition length-error request-error)
(define-condition match-error request-error)
(define-condition name-error request-error)
(define-condition pixmap-error resource-error)
(define-condition property-error request-error)
(define-condition value-error request-error
value)
(define-condition window-error resource-error)
(defmacro with-display ((display) &body body)
;; This macro is for use in a multi-process environment. It provides exclusive
;; access to the local display object for multiple request generation. It need not
;; provide immediate exclusive access for replies; that is, if another process is
;; waiting for a reply (while not in a with-display), then synchronization need not
;; (but can) occur immediately. Except where noted, all routines effectively
;; contain an implicit with-display where needed, so that correct synchronization
;; is always provided at the interface level on a per-call basis. Nested uses of
;; this macro will work correctly. This macro does not prevent concurrent event
;; processing; see with-event-queue.
)
(defun display-force-output (display)
;; Output is normally buffered; this forces any buffered output.
(declare (type display display)))
(defun display-finish-output (display)
;; Forces output, then causes a round-trip to ensure that all possible errors and
;; events have been received.
(declare (type display display)))
(defun display-after-function (display)
;; setf'able
;; If defined, called after every protocol request is generated, even those inside
;; explicit with-display's, but never called from inside the after-function itself.
;; The function is called inside the effective with-display for the associated
;; request. Default value is nil. Can be set, for example, to
;; #'display-force-output or #'display-finish-output.
(declare (type display display)
(values (or null (function (display))))))
(defun create-window (&key parent x y width height (depth 0) (border-width 0)
(class :copy) (visual :copy)
background border gravity bit-gravity
backing-store backing-planes backing-pixel save-under
event-mask do-not-propagate-mask override-redirect
colormap cursor)
;; Display is obtained from parent. Only non-nil attributes are passed on in the
;; request: the function makes no assumptions about what the actual protocol
;; defaults are. Width and height are the inside size, excluding border.
(declare (type window parent)
(type integer x y width height depth border-width)
(type (member :copy :input-output :input-only) class)
(type (or (member :copy) visual) visual)
(type (or null (member :none :parent-relative) integer pixmap) background)
(type (or null (member :copy) integer pixmap) border)
(type (or null win-gravity) gravity)
(type (or null bit-gravity) bit-gravity)
(type (or null (member :not-useful :when-mapped :always) backing-store))
(type (or null integer) backing-planes backing-pixel)
(type (or null event-mask) event-mask)
(type (or null device-event-mask) do-not-propagate-mask)
(type (or null (member :on :off)) save-under override-redirect)
(type (or null (member :copy) colormap) colormap)
(type (or null (member :none) cursor) cursor)
(values window)))
(defun window-class (window)
(declare (type window window)
(values (member :input-output :input-only))))
(defun window-visual (window)
(declare (type window window)
(values integer)))
(defsetf window-background (window) (background)
(declare (type window window)
(type (or (member :none :parent-relative) integer pixmap) background)))
(defsetf window-border (window) (border)
(declare (type window window)
(type (or (member :copy) integer pixmap) border)))
(defun window-gravity (window)
;; setf'able
(declare (type window window)
(values win-gravity)))
(defun window-bit-gravity (window)
;; setf'able
(declare (type window window)
(values bit-gravity)))
(defun window-backing-store (window)
;; setf'able
(declare (type window window)
(values (member :not-useful :when-mapped :always))))
(defun window-backing-planes (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-backing-pixel (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-save-under (window)
;; setf'able
(declare (type window window)
(values (member :on :off))))
(defun window-event-mask (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-do-not-propagate-mask (window)
;; setf'able
(declare (type window window)
(values integer)))
(defun window-override-redirect (window)
;; setf'able
(declare (type window window)
(values (member :on :off))))
(defun window-colormap (window)
(declare (type window window)
(values (or null colormap))))
(defsetf window-colormap (window) (colormap)
(declare (type window window)
(type (or (member :copy) colormap) colormap)))
(defsetf window-cursor (window) (cursor)
(declare (type window window)
(type (or (member :none) cursor) cursor)))
(defun window-colormap-installed-p (window)
(declare (type window window)
(values boolean)))
(defun window-all-event-masks (window)
(declare (type window window)
(values integer)))
(defun window-map-state (window)
(declare (type window window)
(values (member :unmapped :unviewable :viewable))))
(defsetf drawable-x (window) (x)
(declare (type window window)
(type integer x)))
(defsetf drawable-y (window) (y)
(declare (type window window)
(type integer y)))
(defsetf drawable-width (window) (width)
;; Inside width, excluding border.
(declare (type window window)
(type integer width)))
(defsetf drawable-height (window) (height)
;; Inside height, excluding border.
(declare (type window window)
(type integer height)))
(defsetf drawable-border-width (window) (border-width)
(declare (type window window)
(type integer border-width)))
(defsetf window-priority (window &optional sibling) (mode)
;; A bit strange, but retains setf form.
(declare (type window window)
(type (or null window) sibling)
(type (member :above :below :top-if :bottom-if :opposite) mode)))
(defmacro with-state ((drawable) &body body)
;; Allows a consistent view to be obtained of data returned by GetWindowAttributes
;; and GetGeometry, and allows a coherent update using ChangeWindowAttributes and
;; ConfigureWindow. The body is not surrounded by a with-display. Within the
;; indefinite scope of the body, on a per-process basis in a multi-process
;; environment, the first call within an Accessor Group on the specified drawable
;; (the object, not just the variable) causes the complete results of the protocol
;; request to be retained, and returned in any subsequent accessor calls. Calls
;; within a Setf Group are delayed, and executed in a single request on exit from
;; the body. In addition, if a call on a function within an Accessor Group follows
;; a call on a function in the corresponding Setf Group, then all delayed setfs for
;; that group are executed, any retained accessor information for that group is
;; discarded, the corresponding protocol request is (re)issued, and the results are
;; (again) retained, and returned in any subsequent accessor calls.
;; Accessor Group A (for GetWindowAttributes):
;; window-visual, window-class, window-gravity, window-bit-gravity,
;; window-backing-store, window-backing-planes, window-backing-pixel,
;; window-save-under, window-colormap, window-colormap-installed-p,
;; window-map-state, window-all-event-masks, window-event-mask,
;; window-do-not-propagate-mask, window-override-redirect
;; Setf Group A (for ChangeWindowAttributes):
;; window-gravity, window-bit-gravity, window-backing-store, window-backing-planes,
;; window-backing-pixel, window-save-under, window-event-mask,
;; window-do-not-propagate-mask, window-override-redirect, window-colormap,
;; window-cursor
;; Accessor Group G (for GetGeometry):
;; drawable-root, drawable-depth, drawable-x, drawable-y, drawable-width,
;; drawable-height, drawable-border-width
;; Setf Group G (for ConfigureWindow):
;; drawable-x, drawable-y, drawable-width, drawable-height, drawable-border-width,
;; window-priority
)
(defun destroy-window (window)
(declare (type window window)))
(defun destroy-subwindows (window)
(declare (type window window)))
(defun add-to-save-set (window)
(declare (type window window)))
(defun remove-from-save-set (window)
(declare (type window window)))
(defun reparent-window (window parent x y)
(declare (type window window parent)
(type integer x y)))
(defun map-window (window)
(declare (type window window)))
(defun map-subwindows (window)
(declare (type window window)))
(defun unmap-window (window)
(declare (type window window)))
(defun unmap-subwindows (window)
(declare (type window window)))
(defun circulate-window-up (window)
(declare (type window window)))
(defun circulate-window-down (window)
(declare (type window window)))
(defun drawable-root (drawable)
(declare (type drawable drawable)
(values drawable)))
(defun drawable-depth (drawable)
(declare (type drawable drawable)
(values integer)))
(defun drawable-x (drawable)
(declare (type drawable drawable)
(values integer)))
(defun drawable-y (drawable)
(declare (type drawable drawable)
(values integer)))
(defun drawable-width (drawable)
;; For windows, inside width, excluding border.
(declare (type drawable drawable)
(values integer)))
(defun drawable-height (drawable)
;; For windows, inside height, excluding border.
(declare (type drawable drawable)
(values integer)))
(defun drawable-border-width (drawable)
(declare (type drawable drawable)
(values integer)))
(defun query-tree (window &key (result-type 'list))
(declare (type window window)
(type type result-type)
(values (sequence window) parent root)))
(defun change-property (window property data type format
&key (mode :replace) (start 0) end transform)
;; Start and end affect sub-sequence extracted from data.
;; Transform is applied to each extracted element.
(declare (type window window)
(type xatom property type)
(type (member 8 16 32) format)
(type sequence data)
(type (member :replace :prepend :append) mode)
(type integer start)
(type (or null integer) end)
(type (or null (function (t) integer)) transform)))
(defun delete-property (window property)
(declare (type window window)
(type xatom property)))
(defun get-property (window property
&key type (start 0) end delete-p (result-type 'list) transform)
;; Transform is applied to each integer retrieved.
(declare (type window window)
(type xatom property)
(type (or null xatom) type)
(type integer start)
(type (or null integer) end)
(type boolean delete-p)
(type type result-type)
(type (or null (function (integer) t)) transform)
(values data type format bytes-after)))
(defun rotate-properties (window properties &optional (delta 1))
;; Postive rotates left, negative rotates right (opposite of actual protocol request).
(declare (type window window)
(type (sequence xatom) properties)
(type integer delta)))
(defun list-properties (window &key (result-type 'list))
(declare (type window window)
(type type result-type)
(values (sequence keyword))))
;; Although atom-ids are not visible in the normal user interface, atom-ids might
;; appear in window properties and other user data, so conversion hooks are needed.
(defun intern-atom (display name)
(declare (type display display)
(type xatom name)
(values integer)))
(defun find-atom (display name)
(declare (type display display)
(type xatom name)
(values (or null integer))))
(defun atom-name (display atom-id)
(declare (type display display)
(type integer atom-id)
(values keyword)))
(defun selection-owner (display selection)
(declare (type display display)
(type xatom selection)
(values (or null window))))
(defsetf selection-owner (display selection &optional time) (owner)
;; A bit strange, but retains setf form.
(declare (type display display)
(type xatom selection)
(type (or null window) owner)
(type timestamp time)))
(defun convert-selection (selection type requestor &optional property time)
(declare (type xatom selection type)
(type window requestor)
(type (or null xatom) property)
(type timestamp time)))
(defun send-event (window event-key event-mask &rest args
&key propagate-p display &allow-other-keys)
;; Additional arguments depend on event-key, and are as specified further below
;; with declare-event, except that both resource-ids and resource objects are
;; accepted in the event components. The display argument is only required if the
;; window is :pointer-window or :input-focus.
(declare (type (or window (member :pointer-window :input-focus)) window)
(type event-key event-key)
(type event-mask event-mask)
(type boolean propagate-p)
(type (or null display) display)))
(defun grab-pointer (window event-mask
&key owner-p sync-pointer-p sync-keyboard-p confine-to cursor time)
(declare (type window window)
(type pointer-event-mask event-mask)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type (or null window) confine-to)
(type (or null cursor) cursor)
(type timestamp time)
(values grab-status)))
(defun ungrab-pointer (display &key time)
(declare (type display display)
(type timestamp time)))
(defun grab-button (window button event-mask
&key (modifiers 0)
owner-p sync-pointer-p sync-keyboard-p confine-to cursor)
(declare (type window window)
(type (or (member :any) integer) button)
(type modifier-mask modifiers)
(type pointer-event-mask event-mask)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type (or null window) confine-to)
(type (or null cursor) cursor)))
(defun ungrab-button (window button &key (modifiers 0))
(declare (type window window)
(type (or (member :any) integer) button)
(type modifier-mask modifiers)))
(defun change-active-pointer-grab (display event-mask &optional cursor time)
(declare (type display display)
(type pointer-event-mask event-mask)
(type (or null cursor) cursor)
(type timestamp time)))
(defun grab-keyboard (window &key owner-p sync-pointer-p sync-keyboard-p time)
(declare (type window window)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type timestamp time)
(values grab-status)))
(defun ungrab-keyboard (display &key time)
(declare (type display display)
(type timestamp time)))
(defun grab-key (window key &key (modifiers 0) owner-p sync-pointer-p sync-keyboard-p)
(declare (type window window)
(type boolean owner-p sync-pointer-p sync-keyboard-p)
(type (or (member :any) integer) key)
(type modifier-mask modifiers)))
(defun ungrab-key (window key &key (modifiers 0))
(declare (type window window)
(type (or (member :any) integer) key)
(type modifier-mask modifiers)))
(defun allow-events (display mode &optional time)
(declare (type display display)
(type (member :async-pointer :sync-pointer :reply-pointer
:async-keyboard :sync-keyboard :replay-keyboard)
mode)
(type timestamp time)))
(defun grab-server (display)
(declare (type display display)))
(defun ungrab-server (display)
(declare (type display display)))
(defmacro with-server-grabbed ((display) &body body)
;; The body is not surrounded by a with-display.
)
∂31-May-87 0914 MATHIS@ADA20.ISI.EDU CLX part 2 of 2
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 31 May 87 09:14:09 PDT
Return-Path: <RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU>
Date: Sat, 30 May 87 09:57 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: CLX part 2 of 2
To: MATHIS@ADA20.ISI.EDU
Message-ID: <870530095718.6.RWS@KILLINGTON.LCS.MIT.EDU>
ReSent-To: x3j13@SAIL.STANFORD.EDU
ReSent-From: MATHIS at ADA20.ISI.EDU
ReSent-Date: 31 May 1987
(defun query-pointer (window)
(declare (type window window)
(values x y same-screen-p child mask root-x root-y root)))
(defun pointer-position (window)
(declare (type window window)
(values x y same-screen-p)))
(defun global-pointer-position (display)
(declare (type display display)
(values root-x root-y root)))
(defun motion-events (window &key start stop (result-type 'list))
(declare (type window window)
(type timestamp start stop)
(type type result-type)
(values (repeat-seq (integer x) (integer y) (timestamp time)))))
(defun translate-coordinates (src src-x src-y dst)
;; If src and dst are not on the same screen, nil is returned.
(declare (type window src)
(type integer src-x src-y)
(type window dst)
(values dst-x dst-y child)))
(defun warp-pointer (dst dst-x dst-y)
(declare (type window dst)
(type integer dst-x dst-y)))
(defun warp-pointer-if-inside (dst dst-x dst-y src src-x src-y
&optional src-width src-height)
;; Passing in a zero src-width or src-height is a no-op. A null src-width or
;; src-height translates into a zero value in the protocol request.
(declare (type window dst src)
(type integer dst-x dst-y src-x src-y)
(type (or null integer) src-width src-height)))
(defun set-input-focus (display focus revert-to &optional time)
;; Setf ought to allow multiple values.
(declare (type display display)
(type (or (member :none :pointer-root) window) focus)
(type (member :none :parent :pointer-root) revert-to)
(type timestamp time)))
(defun input-focus (display)
(declare (type display display)
(values focus revert-to)))
(defun query-keymap (display)
(declare (type display display)
(values (bit-vector 256))))
(defun open-font (display name &optional (cache-p t))
;; Font objects may be cached and reference counted locally within the display
;; object. This function might not execute a with-display if the font is cached.
;; The protocol QueryFont request happens on-demand under the covers. If cache-p
;; is nil, QueryFont results are never cached locally.
(declare (type display display)
(type stringable name)
(type boolean cache-p)
(values font)))
(defun font-cache-p (font)
;; setf'able
(declare (type font font)
(values boolean)))
(defun font-font-info (font)
(declare (type font font)
(values font-info)))
;; For each component (<name> <unspec> :type <type>) of font-info,
;; there is a corresponding function:
(defun font-<name> (font)
(declare (type font font)
(values <type>)))
(defun font-property (font name)
(declare (type font font)
(type keyword name)
(values (or null integer))))
(defun font-char-infos (font)
(declare (type font font)
(values (array char-info))))
(defun font-char-info (font char)
(declare (type font font)
(type integer char)
(values (or null char-info))))
(defun font-char16-info (font first-byte second-byte)
(declare (type font font)
(type integer first-byte second-byte)
(values (or null char-info))))
(defun close-font (font)
;; This might not generate a protocol request if the font is reference counted
;; locally.
(declare (type font font)))
(defun text-extents (font string)
(declare (type (or font gcontext) font)
(type string string)
(values width ascent descent left right font-ascent font-descent direction)))
(defun text16-extents (font array &key bytes-p)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a string of even length, treated as
;; first-byte/second-byte pairs.
(declare (type (or font gcontext) font)
(type array array)
(type boolean bytes-p)
(values width ascent descent left right font-ascent font-descent direction)))
(defun text-width (font string)
(declare (type (or font gcontext) font)
(type string string)
(values integer)))
(defun text16-width (font array &key bytes-p)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a string of even length, treated as
;; first-byte/second-byte pairs.
(declare (type (or font gcontext) font)
(type array array)
(type boolean bytes-p)
(values integer)))
(defun list-fonts (display pattern &key (max-fonts 65535) (result-type 'list))
(declare (type display display)
(type string pattern)
(type integer max-fonts)
(type type result-type)
(values (sequence string))))
(defun list-fonts-with-info (display pattern &key (max-fonts 65535) (result-type 'list))
(declare (type display display)
(type string pattern)
(type integer max-fonts)
(type type result-type)
(values (sequence font-info))))
(defun font-path (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence (or string pathname)))))
(defsetf font-path (display) (paths)
(declare (type display display)
(type (sequence (or string pathname)) paths)))
(defun create-pixmap (&key width height depth drawable)
(declare (type integer width height depth)
(type drawable drawable)
(values pixmap)))
(defun free-pixmap (pixmap)
(declare (type pixmap pixmap)))
(defun create-gcontext (&key drawable function plane-mask foreground background
line-width line-style cap-style join-style fill-style fill-rule
arc-mode tile stipple ts-x ts-y font subwindow-mode
exposures clip-x clip-y clip-mask clip-ordering
dash-offset dashes
(cache-p t))
;; Only non-nil components are passed on in the request, but for effective caching
;; assumptions have to be made about what the actual protocol defaults are. For
;; all gcontext components, a value of nil causes the default gcontext value to be
;; used. For clip-mask, this implies that an empty rect-seq cannot be represented
;; as a list. Note: use of stringable as font will cause an implicit open-font.
;; Note: papers over protocol SetClipRectangles and SetDashes special cases. If
;; cache-p is true, then gcontext state is cached locally, and changing a gcontext
;; component will have no effect unless the new value differs from the cached
;; value. Component changes (setfs and with-gcontext) are always deferred
;; regardless of the cache mode, and sent over the protocol only when required by a
;; local operation or by an explicit call to force-gcontext-changes.
(declare (type drawable drawable)
(type (or null boole-constant) function)
(type (or null integer) plane-mask foreground background line-width
ts-x ts-y clip-x clip-y dash-offset)
(type (or null (member :solid :dash :double-dash)) line-style)
(type (or null (member :not-last :butt :round :projecting)) cap-style)
(type (or null (member :miter :round :bevel)) join-style)
(type (or null (member :solid :tiled :opaque-stippled :stippled)) fill-style)
(type (or null (member :even-odd :winding)) fill-rule)
(type (or null (member :chord :pie-slice)) arc-mode)
(type (or null pixmap) tile stipple)
(type (or null fontable) font)
(type (or null (member :clip-by-children :include-inferiors)) subwindow-mode)
(type (or null (member :on :off)) exposures)
(type (or null (member :none) pixmap rect-seq) clip-mask)
(type (or null (member :unsorted :y-sorted :yx-sorted :yx-banded)) clip-ordering)
(type (or null (or integer (sequence integer))) dashes)
(type (or null integer) dash-offset)
(type boolean cache)
(values gcontext)))
;; For each argument to create-gcontext (except clip-mask and clip-ordering) declared
;; as (type <type> <name>), there is an accessor:
(defun gcontext-<name> (gcontext)
;; The value will be nil if the last value stored is unknown (e.g., the cache was
;; off, or the component was copied from a gcontext with unknown state).
(declare (type gcontext gcontext)
(values <type>)))
;; For each argument to create-gcontext (except clip-mask and clip-ordering) declared
;; as (type (or null <type>) <name>), there is a setf for the corresponding accessor:
(defsetf gcontext-<name> (gcontext) (value)
(declare (type gcontext gcontext)
(type <type> value)))
(defun gcontext-clip-mask (gcontext)
(declare (type gcontext gcontext)
(values (or null (member :none) pixmap rect-seq)
(or null (member :unsorted :y-sorted :yx-sorted :yx-banded)))))
(defsetf gcontext-clip-mask (gcontext &optional ordering) (clip-mask)
;; Is nil illegal here, or is it transformed to a vector?
;; A bit strange, but retains setf form.
(declare (type gcontext gcontext)
(type (or null (member :unsorted :y-sorted :yx-sorted :yx-banded)) clip-ordering)
(type (or (member :none) pixmap rect-seq) clip-mask)))
(defun force-gcontext-changes (gcontext)
;; Force any delayed changes.
(declare (type gcontext gcontext)))
(defmacro with-gcontext ((gcontext &key
function plane-mask foreground background
line-width line-style cap-style join-style fill-style fill-rule
arc-mode tile stipple ts-x ts-y font subwindow-mode
exposures clip-x clip-y clip-mask clip-ordering
dashes dash-offset)
&body body)
;; Changes gcontext components within the dynamic scope of the body (i.e.,
;; indefinite scope and dynamic extent), on a per-process basis in a multi-process
;; environment. The body is not surrounded by a with-display. If cache-p is nil
;; or the some component states are unknown, this will implement save/restore by
;; creating a temporary gcontext and doing copy-gcontext-components to and from it.
)
(defun copy-gcontext-components (src dst &rest keys)
(declare (type gcontext src dst)
(type (list gcontext-key) keys)))
(defun copy-gcontext (src dst)
(declare (type gcontext src dst))
;; Copies all components.
)
(defun free-gcontext (gcontext)
(declare (type gcontext gcontext)))
(defun clear-area (window &key (x 0) (y 0) width height exposures-p)
;; Passing in a zero width or height is a no-op. A null width or height translates
;; into a zero value in the protocol request.
(declare (type window window)
(type integer x y)
(type (or null integer) width height)
(type boolean exposures-p)))
(defun copy-area (src gcontext src-x src-y width height dst dst-x dst-y)
(declare (type drawable src dst)
(type gcontext gcontext)
(type integer src-x src-y width height dst-x dst-y)))
(defun copy-plane (src gcontext plane src-x src-y width height dst dst-x dst-y)
(declare (type drawable src dst)
(type gcontext gcontext)
(type integer src-x src-y plane width height dst-x dst-y)))
(defun draw-point (drawable gcontext x y)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)))
(defun draw-points (drawable gcontext points &optional relative-p)
(declare (type drawable drawable)
(type gcontext gcontext)
(type point-seq points)
(type boolean relative-p)))
(defun draw-line (drawable gcontext x1 y1 x2 y2 &optional relative-p)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x1 y1 x2 y2)
(type boolean relative-p)))
(defun draw-lines (drawable gcontext points &key relative-p fill-p (shape :complex))
(declare (type drawable drawable)
(type gcontext gcontext)
(type point-seq points)
(type boolean relative-p fill-p)
(type (member :complex :non-convex :convex) shape)))
(defun draw-segments (drawable gcontext segments)
(declare (type drawable drawable)
(type gcontext gcontext)
(type seg-seq segments)))
(defun draw-rectangle (drawable gcontext x y width height &optional fill-p)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y width height)
(type boolean fill-p)))
(defun draw-rectangles (drawable gcontext rectangles &optional fill-p)
(declare (type drawable drawable)
(type gcontext gcontext)
(type rect-seq rectangles)
(type boolean fill-p)))
(defun draw-arc (drawable gcontext x y width height angle1 angle2 &optional fill-p)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y width height angle1 angle2)
(type boolean fill-p)))
(defun draw-arcs (drawable gcontext arcs &optional fill-p)
(declare (type drawable drawable)
(type gcontext gcontext)
(type arc-seq arcs)
(type boolean fill-p)))
;; The following image routines are bare minimum. It may be useful to define some
;; form of "image" object to hide representation details and format conversions. It
;; also may be useful to provide stream-oriented interfaces for reading and writing
;; the data.
(defun put-raw-image (drawable gcontext data
&key (start 0) depth x y width height (left-pad 0) format)
;; Data must be a sequence of 8-bit quantities, already in the appropriate format
;; for transmission; the caller is responsible for all byte and bit swapping and
;; compaction. Start is the starting index in data; the end is computed from the
;; other arguments.
(declare (type drawable drawable)
(type gcontext gcontext)
(type (sequence integer) data)
(type integer start depth x y width height left-pad)
(type (member :bitmap :xy-pixmap :z-pixmap) format)))
(defun get-raw-image (drawable &key data (start 0) x y width height (plane-mask -1) format
(result-type '(vector (unsigned-byte 8))))
;; If data is given, it is modified in place (and returned), otherwise a new
;; sequence is created and returned, with a size computed from the other arguments
;; and the returned depth. The sequence is filled with 8-bit quantities, in
;; transmission format; the caller is responsible for any byte and bit swapping and
;; compaction required for further local use.
(declare (type drawable drawable)
(type (or null (sequence integer)) data)
(type integer start x y width height plane-mask)
(type (member :xy-format z-format) format)
(values (sequence integer) depth visual)))
(defun draw-string (drawable gcontext x y string &key (start 0) end)
;; For 8-bit indexes only.
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified and char-infos are cached.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type string string)
(type (or null integer) end)))
(defun draw-text (drawable gcontext items)
;; For 8-bit indexes only.
;; Items is a flat sequence containing both triples and pairs of the form:
;; (integer x) (integer y) (string string)
;; :font (fontable font)
(declare (type drawable drawable)
(type gcontext gcontext)
(type sequence items)))
(defun draw-string16 (drawable gcontext x y array &key bytes-p (start 0) end)
;; Should be clever about appending to existing buffered protocol request, provided
;; gcontext has not been modified and char-infos are cached. If bytes-p is nil,
;; then array should be an array of integers to be treated as 16-bit quantities,
;; otherwise array should be a string of even length, treated as
;; first-byte/second-byte pairs.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type array array)
(type boolean bytes-p)))
(defun draw-text16 (drawable gcontext items &key bytes-p)
;; Items is a flat sequence containing both triples and pairs of the form:
;; (integer x) (integer y) (array array)
;; :font (fontable font)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a (sub)string of even length,
;; treated as first-byte/second-byte pairs.
(declare (type drawable drawable)
(type gcontext gcontext)
(type sequence items)
(type boolean bytes-p)
(type (or null integer) end)))
(defun draw-image-string (drawable gcontext x y string &key (start 0) end)
;; For 8-bit indexes only.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y start)
(type string string)
(type (or null integer) end)))
(defun draw-image-string16 (drawable gcontext x y array &key bytes-p (start 0) end)
;; If bytes-p is nil, then array should be an array of integers to be treated as
;; 16-bit quantities, otherwise array should be a (sub)string of even length,
;; treated as first-byte/second-byte pairs.
(declare (type drawable drawable)
(type gcontext gcontext)
(type integer x y)
(type array array)
(type boolean bytes-p)
(type (or null integer) end)))
(defun create-colormap (visual window &optional alloc-p)
(declare (type integer visual)
(type window window)
(type boolean alloc-p)
(values colormap)))
(defun free-colormap (colormap)
(declare (type colormap colormap)))
(defun copy-colormap-and-free (colormap)
(declare (type colormap colormap)
(values colormap)))
(defun install-colormap (colormap)
(declare (type colormap colormap)))
(defun uninstall-colormap (colormap)
(declare (type colormap colormap)))
(defun installed-colormaps (window &key (result-type 'list))
(declare (type window window)
(type type result-type)
(values (sequence colormap))))
(defun alloc-color (colormap color)
(declare (type colormap colormap)
(type (or stringable color) color)
(values pixel screen-color exact-color)))
(defun alloc-color-cells (colormap colors &key (planes 0) contiguous-p (result-type 'list))
(declare (type colormap colormap)
(type integer colors planes)
(type boolean contiguous-p)
(type type result-type)
(values (sequence pixel) (sequence mask))))
(defun alloc-color-planes (colormap colors
&key (reds 0) (greens 0) (blues 0)
contiguous-p (result-type 'list))
(declare (type colormap colormap)
(type integer colors reds greens blues)
(type boolean contiguous-p)
(type type result-type)
(values (sequence pixel) red-mask green-mask blue-mask)))
(defun free-colors (colormap pixels &optional (plane-mask 0))
(declare (type colormap colormap)
(type (sequence integer) pixels)
(type integer plane-mask)))
(defun store-color (colormap pixel spec &key (red-p t) (green-p t) (blue-p t))
(declare (type colormap colormap)
(type integer pixel)
(type (or stringable color) spec)
(type boolean red-p green-p blue-p)))
(defun store-colors (colormap specs &key (red-p t) (green-p t) (blue-p t))
;; If stringables are specified for colors, it is unspecified whether all
;; stringables are first resolved and then a single StoreColors protocol request is
;; issued, or whether multiple StoreColors protocol requests are issued.
(declare (type colormap colormap)
(type (repeat-seq (integer pixel) ((or stringable color) color)) specs)
(type boolean red-p green-p blue-p)))
(defun query-colors (colormap pixels &key (result-type 'list))
(declare (type colormap colormap)
(type (sequence integer) pixels)
(type type result-type)
(values (sequence color))))
(defun lookup-color (colormap name)
(declare (type colormap colormap)
(type stringable name)
(values screen-color true-color)))
(defun create-cursor (&key source mask x y foreground background)
(declare (type pixmap source)
(type (or null pixmap) mask)
(type integer x y)
(type color foreground background)
(values cursor)))
(defun create-glyph-cursor (&key source-font source-char mask-font mask-char
foreground background)
(declare (type font source-font)
(type integer source-char)
(type (or null font) mask-font)
(type (or null integer) mask-char)
(type color foreground background)
(values cursor)))
(defun free-cursor (cursor)
(declare (type cursor cursor)))
(defun recolor-cursor (cursor foreground background)
(declare (type cursor cursor)
(type color foreground background)))
(defun query-best-cursor (width height display)
(declare (type integer width height)
(type display display)
(values width height)))
(defun query-best-tile (width height drawable)
(declare (type integer width height)
(type drawable drawable)
(values width height)))
(defun query-best-stipple (width height drawable)
(declare (type integer width height)
(type drawable drawable)
(values width height)))
(defun query-extension (display name)
(declare (type display display)
(type stringable name)
(values major-opcode first-event first-error)))
(defun list-extensions (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence string))))
(defun keyboard-mapping (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence integer))))
(define-condition device-busy error)
(defsetf keyboard-mapping (display) (map)
;; Can signal device-busy.
(declare (type display display)
(type (sequence integer) map)))
(defun change-keyboard-control (display &key key-click-percent
bell-percent bell-pitch bell-duration
led led-mode key auto-repeat-mode)
(declare (type display display)
(type (or null (member :default) integer) key-click-percent
bell-percent bell-pitch bell-duration)
(type (or null integer) led key)
(type (or null (member :on :off)) led-mode)
(type (or null (member :on :off :default)) auto-repeat-mode)))
(defun keyboard-control (display)
(declare (type display display)
(values key-click-percent bell-percent bell-pitch bell-duration
led-mask global-auto-repeat auto-repeats)))
(defun bell (display &optional (percent-from-normal 0))
;; It is assumed that an eventual audio extension to X will provide more complete
;; control.
(declare (type display display)
(type integer percent-from-normal)))
(defun pointer-mapping (display &key (result-type 'list))
(declare (type display display)
(type type result-type)
(values (sequence integer))))
(defsetf pointer-mapping (display) (map)
;; Can signal device-busy.
(declare (type display display)
(type (sequence integer) map)))
(defun change-pointer-control (display &key acceleration threshold)
;; Acceleration is rationalized if necessary.
(declare (type display display)
(type (or null (member :default) number) acceleration)
(type (or null (member :default) integer) threshold)))
(defun pointer-control (display)
(declare (type display display)
(values acceleration threshold)))
(defun set-screen-saver (display timeout interval blanking exposures)
;; Setf ought to allow multiple values.
;; Timeout and interval are in seconds, will be rounded to minutes.
(declare (type display display)
(type (or (member :default) integer) timeout interval)
(type (member :yes :no :default) blanking exposures)))
(defun screen-saver (display)
;; Returns timeout and interval in seconds.
(declare (type display display)
(values timeout interval blanking exposures)))
(defun activate-screen-saver (display)
(declare (type display display)))
(defun reset-screen-saver (display)
(declare (type display display)))
(defun add-access-host (display host)
;; A string must be acceptable as a host, but otherwise the possible types for host
;; are not constrained, and will likely be very system dependent.
(declare (type display display)))
(defun remove-access-host (display host)
;; A string must be acceptable as a host, but otherwise the possible types for host
;; are not constrained, and will likely be very system dependent.
(declare (type display display)))
(defun access-hosts (display &key (result-type 'list))
;; The type of host objects returned is not constrained, except that the hosts must
;; be acceptable to add-access-host and remove-access-host.
(declare (type display display)
(type type result-type)
(values (sequence host) enabled-p)))
(defun access-control (display)
;; setf'able
(declare (type display display)
(values boolean)))
(defun close-down-mode (display)
;; setf'able
;; Cached locally in display object.
(declare (type display display)
(values (member :destroy :retain-permanent :retain-temporary))))
(defun kill-client (display resource-id)
(declare (type display display)
(type resource-id resource-id)))
(defun kill-temporary-clients (display)
(declare (type display display)))
(defun make-event-mask (&rest keys)
;; This is only defined for core events.
;; Useful for constructing event-mask, pointer-event-mask, device-event-mask.
(declare (type (list event-mask-class) keys)
(values integer)))
(defun make-event-keys (event-mask)
;; This is only defined for core events.
(declare (type integer event-mask)
(values (list event-mask-class))))
(defun make-state-mask (&rest keys)
;; Useful for constructing modifier-mask, state-mask.
(declare (type (list state-mask-key) keys)
(values integer)))
(defun make-state-keys (state-mask)
(declare (type integer mask)
(values (list state-mask-key))))
(defmacro with-event-queue ((display) &body body)
;; Grants exclusive access to event queue.
)
(defun event-listen (display &optional (timeout 0))
(declare (type display display)
(type (or null number) timeout))
;; Returns the number of events queued locally, if any, else nil. Hangs waiting
;; for events, forever if timeout is nil, else for the specified number of seconds.
)
(defun process-event (display &key handler timeout peek-p discard-p force-output-p)
;; If force-output-p is true, first invokes display-force-output. Invokes handler
;; on each queued event until handler returns non-nil, and that returned object is
;; then returned by process-event. If peek-p is true, then the event is not
;; removed from the queue. If discard-p is true, then events for which handler
;; returns nil are removed from the queue, otherwise they are left in place. Hangs
;; until non-nil is generated for some event, or for the specified timeout (in
;; seconds, if given); however, it is acceptable for an implementation to wait only
;; once on network data, and therefore timeout prematurely. Returns nil on
;; timeout. If handler is a sequence, it is expected to contain handler functions
;; specific to each event class; the event code is used to index the sequence,
;; fetching the appropriate handler. Handler is called with raw resource-ids, not
;; with resource objects. The arguments to the handler are described further below
;; using declare-event.
(declare (type display display)
(type (or (sequence (function (&rest key-vals) t))
(function (&rest key-vals) t))
handler)
(type (or null number) timeout)
(type boolean peek-p)))
(defmacro event-case ((display &key timeout peek-p discard-p force-output-p)
&body clauses)
(declare (arglist (display &key timeout peek-p discard-p force-output-p)
(event-or-events ((&rest args) |...|) &body body) |...|))
;; If force-output-p is true, first invokes display-force-output. Executes the
;; matching clause for each queued event until a clause returns non-nil, and that
;; returned object is then returned by event-case. If peek-p is true, then the
;; event is not removed from the queue. If discard-p is true, then events for
;; which the clause returns nil are removed from the queue, otherwise they are left
;; in place. Hangs until non-nil is generated for some event, or for the specified
;; timeout (in seconds, if given); however, it is acceptable for an implementation
;; to wait only once on network data, and therefore timeout prematurely. Returns
;; nil on timeout. In each clause, event-or-events is an event-key or a list of
;; event-keys (but they need not be typed as keywords) or the symbol t or otherwise
;; (but only in the last clause). The keys are not evaluated, and it is an error
;; for the same key to appear in more than one clause. Args is the list of event
;; components of interest; corresponding values (if any) are bound to variables
;; with these names (i.e., the args are variable names, not keywords, the keywords
;; are derived from the variable names). An arg can also be a (keyword var) form,
;; as for keyword args in a lambda lists. If no t/otherwise clause appears, it is
;; equivalent to having one that returns nil.
)
(defmacro declare-event (event-codes &rest declares)
;; Used to indicate the keyword arguments for handler functions in process-event
;; and event-case. All process-event handlers can have (display display) and
;; (event-key event-key) as keyword arguments, and an event-case clause can also
;; have event-key as an argument.
(declare (arglist event-key-or-keys &rest (type &rest keywords))))
(declare-event (:key-press :key-release :button-press :button-release)
(resource-id window root)
((or null resource-id) child)
(boolean same-screen-p)
(integer x y root-x root-y state time)
;; for key-press and key-release, code is the keycode
;; for button-press and button-release, code is the button number
(integer code))
(declare-event :motion-notify
(resource-id window root)
((or null resource-id) child)
(boolean same-screen-p)
(integer x y root-x root-y state time)
(boolean hint-p))
(declare-event (:enter-notify :leave-notify)
(resource-id window root)
((or null resource-id) child)
(boolean same-screen-p)
(integer x y root-x root-y state time)
((member :normal :grab :ungrab) mode)
((member :ancestor :virtual :inferior :nonlinear :nonlinear-virtual) kind)
(boolean focus-p))
(declare-event (:focus-in :focus-out)
(resource-id window)
((member :normal :while-grabbed :grab :ungrab) mode)
((member :ancestor :virtual :inferior :nonlinear :nonlinear-virtual
:pointer :pointer-root :none)
kind))
(declare-event :keymap-notify
(resource-id window)
((bit-vector 256) keymap))
(declare-event :exposure
(resource-id window)
(integer x y width height)
(boolean last-p))
(declare-event :graphics-exposure
(resource-id drawable)
(integer x y width height major minor)
(boolean last-p))
(declare-event :no-exposure
(resource-id drawable)
(integer major minor))
(declare-event :visibility-notify
(resource-id window)
((member :unobscured :partially-obscured :fully-obscured) state))
(declare-event :create-notify
(resource-id window parent)
(integer x y width height border-width)
(boolean override-redirect-p))
(declare-event :destroy-notify
(resource-id event-window window))
(declare-event :unmap-notify
(resource-id event-window window)
(boolean configure-p))
(declare-event :map-notify
(resource-id event-window window)
(boolean override-redirect-p))
(declare-event :map-request
(resource-id parent window))
(declare-event :reparent-notify
(resource-id event-window window parent)
(integer x y)
(boolean override-redirect-p))
(declare-event :configure-notify
(resource-id event-window window)
(integer x y width height border-width)
((or null resource-id) above-sibling)
(boolean override-redirect-p))
(declare-event :gravity-notify
(resource-id event-window window)
(integer x y))
(declare-event :resize-request
(resource-id window)
(integer width height))
(declare-event :configure-request
(resource-id parent window)
(integer x y width height border-width)
((or null resource-id) above-sibling))
(declare-event :circulate-notify
(resource-id event-window window)
((member :top :bottom) place))
(declare-event :circulate-request
(resource-id parent window)
((member :top :bottom) place))
(declare-event :property-notify
(resource-id window)
(keyword atom)
((member :new-value :deleted) state)
(integer time))
(declare-event :selection-clear
(resource-id window)
(keyword selection)
(integer time))
(declare-event :selection-request
(resource-id window requestor)
(keyword selection target)
((or null keyword) property)
(integer time))
(declare-event :selection-notify
(resource-id window)
(keyword selection target)
((or null keyword) property)
(integer time))
(declare-event :colormap-notify
(resource-id window)
((or null resource-id) colormap)
(boolean new-p installed-p))
(declare-event :client-message
(resource-id window)
((member 8 16 32) format)
((sequence integer) data))
(defun queue-event (display event-key &rest args &key append-p &allow-other-keys)
;; The event is put at the head of the queue if append-p is nil, else the tail.
;; Additional arguments depend on event-key, and are as specified above with
;; declare-event, except that both resource-ids and resource objects are accepted
;; in the event components.
(declare (type display display)
(type event-key event-key)
(type boolean append-p)))
∂01-Jun-87 0532 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol script
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:32:24 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:31-EDT
Date: Mon, 1 Jun 87 08:31 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol script
To: x3j13@sail.stanford.edu
Message-ID: <870601083150.2.RWS@KILLINGTON.LCS.MIT.EDU>
Mathis requested that I mail out the X protocol document.
I just did, in 6 parts. If you are going to print it
out, and have access to a Unix system, below is a shell
script for generating a toc and an index. Be sure to
set the page length for your printer.
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create:
# paginate
# addindex
# This archive created: Fri May 29 11:37:31 1987
export PATH; PATH=/bin:/usr/bin:$PATH
if test -f 'paginate'
then
echo shar: "will not over-write existing file 'paginate'"
else
cat << \SHAR_EOF > 'paginate'
#!/bin/sh
# Hack attack.
# Assuming this program is stilled called paginate, it is intended to be
# in the form
# paginate spec
# It then generates the files
# spec.paged nearly the same as foo with the exception of
# a header on the top of each page. Pages are
# assumed to be 58 lines long before the header
# gets added.
# spec.toc A page number listing of all the lines that start
# with an upper case letter in column 1, up to but
# not including the first colon.
# spec.index An index built from the x11.spec.toc lines.
today="`date`"
linesPerPage=58
infile=$1
pagedfile=$1.paged
indexfile=$1.index
tocfile=$1.toc
addindex=addindex
wordsfile=/usr/tmp/$1.words
indexinput=/usr/tmp/$1.index-input
grepscript=/usr/tmp/$1.grep-script
rm -f $pagedfile $tocfile $indexfile $wordsfile $grepscript
rm -f $indexinput
echo "Paginating $infile into $pagedfile."
awk '
BEGIN {
date = "'"$today"'";
n = split(date, dateparts);
date = dateparts[3] " " dateparts[2] " " dateparts[6]
FS = ":";
input = "'$infile'";
paged = "'$pagedfile'";
toc = "'$tocfile'";
ind = "'$indexfile'";
words = "'$wordsfile'";
page = 1;
line = 0;
}
{
if ((line == 0) && (NF > 0))
printf("\n") > paged
print > paged
line = line + 1
if (line >= '$linesPerPage') {
page = page + 1
line = 0
printf("%c\n%s%42s%23s %d\n", 12, date, "X/V11 Protocol Specification", "Page", page) > paged
}
}
/↑[A-Z]/ {
l = $1;
while ((length(l) % 4) != 0)
l = l " "
while (length(l) < 70)
l = l " ."
if (l ~ /↑SECTION/)
printf("\n") > toc
printf("%s%5d\n", l, page) > toc
if (l !~ /↑SECTION/)
printf("\"%s\"\n", $1) > words
}
' $infile
cat $addindex >> $wordsfile
echo "Sorting $wordsfile."
sort -udf $wordsfile -o $wordsfile
echo "Generating $grepscript."
awk '{print "echo",$0, "; grep -n", $0, "'$infile'" > "'$grepscript'"}' $wordsfile
echo "Executing $grepscript to generate $indexinput."
sh $grepscript > $indexinput
echo "Producing $indexfile."
awk -F: '
BEGIN {
ind = "'$indexfile'";
}
/↑[A-Z]/ {
if (length(line) > 0)
printf("%s\n", line) > ind
line = sprintf("%-25s", $0)
separator = " "
lastPage = 0
}
/↑[0-9]/ {
pagen = ($1+'$linesPerPage'-1)/'$linesPerPage'
t = split(pagen, pageparts, ".")
page = pageparts[1]
if (lastPage != page)
{
if (length(line) > 73)
{
printf("%s,\n", line) > ind
line = sprintf("%-25s %d", " ", page)
}
else
line = line separator page
separator = ", "
lastPage = page
}
}
END {
printf("%s\n", line) > ind
}
' $indexinput
echo "Cleaning up."
#rm -f $wordsfile $grepscript $indexinput
SHAR_EOF
chmod +x 'paginate'
fi
if test -f 'addindex'
then
echo shar: "will not over-write existing file 'addindex'"
else
cat << \SHAR_EOF > 'addindex'
"OwnerGrabButton"
"EnterWindow"
"LeaveWindow"
"PointerMotion"
"PointerMotionHint"
"ButtonMotion"
"VisibilityChange"
"StructureNotify"
"ResizeRedirect"
"SubstructureNotify"
"SubstructureRedirect"
"FocusChange"
"PropertyChange"
"ColormapChange"
"KeymapState"
SHAR_EOF
fi
exit 0
# End of shell archive
∂01-Jun-87 0528 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 3 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:28:25 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:27-EDT
Date: Mon, 1 Jun 87 08:27 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 3 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082750.8.RWS@KILLINGTON.LCS.MIT.EDU>
GetGeometry
drawable: DRAWABLE
=>
root: WINDOW
depth: CARD8
x, y: INT16
width, height, border-width: CARD16
Errors: Drawable
Returns the root and (current) geometry of the drawable. Depth is the
number of bits per pixel for the object. X, y, and border-width will
always be zero for pixmaps. For a window, the x and y coordinates
specify the upper left outer corner of the window relative to its
parent's origin, and the width and height specify the inside size (not
including the border).
It is legal to pass an InputOnly window as a drawable to this request.
QueryTree
window: WINDOW
=>
root: WINDOW
parent: WINDOW or None
children: LISTofWINDOW
Errors: Window
Returns the root, the parent, and children of the window. The children
are listed in bottom-to-top stacking order.
InternAtom
name: STRING8
only-if-exists: BOOL
=>
atom: ATOM or None
Errors: Value, Alloc
Returns the atom for the given name. If only-if-exists is False, then
the atom is created if it does not exist. The string should use the
ASCII encoding, and upper/lower case matters.
The lifetime of an atom is not tied to the interning client. Atoms
remained defined until server reset (see Section 11).
GetAtomName
atom: ATOM
=>
name: STRING8
Errors: Atom
Returns the name for the given atom.
ChangeProperty
window: WINDOW
property, type: ATOM
format: {8, 16, 32}
mode: {Replace, Prepend, Append}
data: LISTofINT8 or LISTofINT16 or LISTofINT32
Errors: Window, Atom, Value, Match, Alloc
Alters the property for the specified window. The type is
uninterpreted by the server. The format specifies whether the data
should be viewed as a list of 8-bit, 16-bit, or 32-bit quantities, so
that the server can correctly byte-swap as necessary.
If mode is Replace, the previous property value is discarded. If the
mode is Prepend or Append, then the type and format must match the
existing property value (else a Match error); if the property is
undefined, it is treated as defined with the correct type and format
with zero-length data. For Prepend, the data is tacked on to the
beginning of the existing data, and for Append it is tacked on to the
end of the existing data.
Generates a PropertyNotify event on the window.
The lifetime of a property is not tied to the storing client.
Properties remain until explicitly deleted, or the window is destroyed,
or until server reset (see Section 11).
The maximum size of a property is server dependent.
DeleteProperty
window: WINDOW
property: ATOM
Errors: Window, Atom
Deletes the property from the specified window if the property exists.
Generates a PropertyNotify event on the window unless the property does
not exist.
GetProperty
window: WINDOW
property: ATOM
type: ATOM or AnyPropertyType
long-offset, long-length: CARD32
delete: BOOL
=>
type: ATOM
format: {8, 16, 32}
bytes-after: CARD32
value: LISTofINT8 or LISTofINT16 or LISTofINT32
Errors: Window, Atom, Property, Match, Value
If the specified property does not exist for the specifed window, a
Property error is generated. Otherwise, if type AnyPropertyType is
specified, (part of) the property is returned regardless of its type;
if a type is specified, (part of) the property is returned only if its
type equals the specified type (else a Match error). The actual type
and format of the property are returned.
Define the following values:
N = actual length of the stored property in bytes
(even if the format is 16 or 32)
I = 4 * long-offset
T = N - I
L = MINIMUM(T, 4 * long-length)
A = N - (I + L)
The returned value starts at byte index I in the property (indexing
from 0), and its length in bytes is L. It is a Value error if
long-offset is given such that L is negative. The value of bytes-after
is A, giving the number of trailing unread bytes in the stored
property.
If delete is True and bytes-after is zero, the property is also deleted
from the window and a PropertyNotify event is generated on the window.
RotateProperties
window: WINDOW
delta: INT8
properties: LISTofATOM
Errors: Window, Atom, Match
If the property names in the list are viewed as being numbered starting
from zero, and there are N property names in the list, then the value
associated with property name I becomes the value associated with
property name (I + delta) mod N, for all I from zero to N - 1. The
effect is to rotate the states by delta places around the virtual ring
of property names (right for positive delta, left for negative delta).
A PropertyNotify event is generated for each property, in the order
listed.
If an atom occurs more than once in the list or no property with that
name is defined for the window, a Match error is generated. If an Atom
or Match error is generated, no properties are changed.
ListProperties
window: WINDOW
=>
atoms: LISTofATOM
Errors: Window
Returns the atoms of properties currently defined on the window.
SetSelectionOwner
selection: ATOM
owner: WINDOW or None
time: TIMESTAMP or CurrentTime
Error: Atom, Window
Changes the owner and last-change time of the specifed selection. The
request has no effect if the specified time is earlier than the current
last-change time of the specified selection or is later than the
current server time; otherwise, the last-change time is set to the
specified time, with CurrentTime replaced by the current server time.
If the new owner is not the same as the current owner of the selection,
and the current owner is a window, then the current owner is sent a
SelectionClear event.
If the owner of a selection is a window, and the window is later
destroyed, the owner of the selection automatically reverts to None,
but the last-change time is not affected.
The selection atom is uninterpreted by the server.
Selections are global to the server.
GetSelectionOwner
selection: ATOM
=>
owner: WINDOW or None
Errors: Atom
Returns the current owner of the specified selection, if any.
ConvertSelection
selection, target: ATOM
property: ATOM or None
requestor: WINDOW
time: TIMESTAMP or CurrentTime
Error: Atom, Window
If the specified selection is owned by a window, the server sends a
SelectionRequest event to the owner. If no owner for the specified
selection exists, the server generates a SelectionNotify event to the
requestor with property None. The arguments are passed on unchanged in
either event.
SendEvent
destination: WINDOW or PointerWindow or InputFocus
propagate: BOOL
event-mask: SETofEVENT
event: <normal-event-format>
Errors: Window, Value
If PointerWindow is specified, destination is replaced with the window
that the pointer is in. If InputFocus is specified, then if the focus
window contains the pointer, destination is replaced with the window
that the pointer is in, and otherwise destination is replaced with the
focus window.
If propagate is False, then the event is sent to every client selecting
on destination any of the event types in event-mask.
If propagate is True and no clients have selected on destination any of
the event types in event-mask, then destination is replaced with the
closest ancestor of destination for which some client has selected a
type in event-mask and no intervening window has that type in its
do-not-propagate-mask. If no such window exists, or if the window is
an ancestor of the focus window and InputFocus was originally specified
as the destination, then the event is not sent to any clients.
Otherwise, the event is reported to every client selecting on the final
destination any of the types specified in event-mask.
The event code must be one of the core events, or one of the events
defined by an extension, so that the server can correctly byte swap the
contents as necessary. The contents of the event are otherwise
unaltered and unchecked by the server except to force on the most
significant bit of the event code.
Active grabs are ignored for this request.
GrabPointer
grab-window: WINDOW
owner-events: BOOL
event-mask: SETofPOINTEREVENT
pointer-mode, keyboard-mode: {Synchronous, Asynchronous}
confine-to: WINDOW or None
cursor: CURSOR or None
time: TIMESTAMP or CurrentTime
=>
status: {Success, AlreadyGrabbed, Frozen, InvalidTime, NotViewable}
Errors: Cursor, Window, Value
Actively grabs control of the pointer. Further pointer events are only
reported to the grabbing client. The request overrides any active
pointer grab by this client.
Event-mask is always augmented to include ButtonPress and
ButtonRelease. If owner-events is False, all generated pointer events
are reported with respect to grab-window, and are only reported if
selected by event-mask. If owner-events is True, then if a generated
pointer event would normally be reported to this client, it is reported
normally; otherwise the event is reported with respect to the
grab-window, and is only reported if selected by event-mask. For
either value of owner-events, unreported events are simply discarded.
Pointer-mode controls further processing of pointer events, and
keyboard-mode controls further processing of keyboard events. If the
mode is Asynchronous, event processing continues normally; if the
device is currently frozen by this client, then processing of events
for the device is resumed. If the mode is Synchronous, the device (as
seen via the protocol) appears to freeze, and no further events for
that device are generated by the server until the grabbing client
issues a releasing AllowEvents request. Actual device changes are not
lost while the device is frozen; they are simply queued for later
processing.
If a cursor is specified, then it is displayed regardless of what
window the pointer is in. If no cursor is specified, then when the
pointer is in grab-window or one of its subwindows, the normal cursor
for that window is displayed, and otherwise the cursor for grab-window
is displayed.
If a confine-to window is specified, then the pointer will be
restricted to stay contained in that window. The confine-to window
need have no relationship to the grab-window. If the pointer is not
initially in the confine-to window, then it is warped automatically to
the closest edge (and enter/leave events generated normally) just
before the grab activates. If the confine-to window is subsequently
reconfigured, the pointer will be warped automatically as necessary to
keep it contained in the window.
This request generates EnterNotify and LeaveNotify events.
The request fails with status AlreadyGrabbed if the pointer is actively
grabbed by some other client. The request fails with status Frozen if
the pointer is frozen by an active grab of another client. The request
fails with status NotViewable if grab-window or confine-to window is
not viewable. The request fails with status InvalidTime if the
specified time is earlier than the last-pointer-grab time or later than
the current server time; otherwise the last-pointer-grab time is set to
the specified time, with CurrentTime replaced by the current server
time.
UngrabPointer
time: TIMESTAMP or CurrentTime
Releases the pointer if this client has it actively grabbed (from
either GrabPointer or GrabButton or from a normal button press), and
releases any queued events. The request has no effect if the specified
time is earlier than the last-pointer-grab time or is later than the
current server time.
This request generates EnterNotify and LeaveNotify events.
An UngrabPointer is performed automatically if the event window or
confine-to window for an active pointer grab becomes not viewable.
GrabButton
modifiers: SETofKEYMASK or AnyModifier
button: BUTTON or AnyButton
grab-window: WINDOW
owner-events: BOOL
event-mask: SETofPOINTEREVENT
pointer-mode, keyboard-mode: {Synchronous, Asynchronous}
confine-to: WINDOW or None
cursor: CURSOR or None
Errors: Cursor, Window, Value, Access
This request establishes a passive grab. In the future, if the
specified button is pressed when the specified modifier keys are down
(and no other buttons or modifier keys are down), and grab-window
contains the pointer, and the confine-to window (if any) is viewable,
and these constraints are not satisfied for any ancestor, then the
pointer is actively grabbed as described in GrabPointer, the
last-pointer-grab time is set to the time at which the button was
pressed (as transmitted in the ButtonPress event), and the ButtonPress
event is reported. The interpretation of the remaining arguments is as
for GrabPointer. The active grab is terminated automatically when all
buttons are released (independent of the state of modifier keys).
A modifiers of AnyModifier is equivalent to issuing the request for all
possible modifier combinations. A button of AnyButton is equivalent to
issuing the request for all possible buttons.
An Access error is generated if some other client has already issued a
GrabButton with the same button/key combination on the same window.
When using AnyModifier or AnyButton, the request fails completely (no
grabs are established) if there is a conflicting grab for any
combination. The request has no effect on an active grab.
UngrabButton
modifiers: SETofKEYMASK or AnyModifier
button: BUTTON or AnyButton
grab-window: WINDOW
Errors: Window
Releases the passive button/key combination on the specified window if
it was grabbed by this client. A modifiers of AnyModifier is
equivalent to issuing the request for all possible modifier
combinations. A button of AnyButton is equivalent to issuing the
request for all possible buttons. Has no effect on an active grab.
ChangeActivePointerGrab
event-mask: SETofPOINTEREVENT
cursor: CURSOR or None
time: TIMESTAMP or CurrentTime
Errors: Cursor
Changes the specified dynamic parameters if the pointer is actively
grabbed by the client and the specified time is no earlier than the
last-pointer-grab time and no later than the current server time. The
interpretation of event-mask and cursor are as in GrabPointer. The
event-mask is always augmented to include ButtonPress and
ButtonRelease. Has no effect on the passive parameters of a
GrabButton.
GrabKeyboard
grab-window: WINDOW
owner-events: BOOL
pointer-mode, keyboard-mode: {Synchronous, Asynchronous}
time: TIMESTAMP or CurrentTime
=>
status: {Success, AlreadyGrabbed, Frozen, InvalidTime, NotViewable}
Errors: Window, Value
Actively grabs control of the keyboard. Further key events are
reported only to the grabbing client. The request overrides any active
keyboard grab by this client.
If owner-events is False, all generated key events are reported with
respect to grab-window. If owner-events is True, then if a generated
key event would normally be reported to this client, it is reported
normally; otherwise the event is reported with respect to the
grab-window. Both KeyPress and KeyRelease events are always reported,
independent of any event selection made by the client.
Pointer-mode controls further processing of pointer events, and
keyboard-mode controls further processing of keyboard events. If the
mode is Asynchronous, event processing continues normally; if the
device is currently frozen by this client, then processing of events
for the device is resumed. If the mode is Synchronous, the device (as
seen via the protocol) appears to freeze, and no further events for
that device are generated by the server until the grabbing client
issues a releasing AllowEvents request. Actual device changes are not
lost while the device is frozen; they are simply queued for later
processing.
This request generates FocusIn and FocusOut events.
The request fails with status AlreadyGrabbed if the keyboard is
actively grabbed by some other client. The request fails with status
Frozen if the keyboard is frozen by an active grab of another client.
The request fails with status NotViewable if grab-window is not
viewable. The request fails with status InvalidTime if the specified
time is earlier than the last-keyboard-grab time or later than the
current server time; otherwise the last-keyboard-grab time is set to
the specified time, with CurrentTime replaced by the current server
time.
UngrabKeyboard
time: TIMESTAMP or CurrentTime
Releases the keyboard if this client has it actively grabbed (from
either GrabKeyboard or GrabKey), and releases any queued events. The
request has no effect if the specified time is earlier than the
last-keyboard-grab time or is later than the current server time.
This request generates FocusIn and FocusOut events.
An UngrabKeyboard is performed automatically if the event window for an
active keyboard grab becomes not viewable.
GrabKey
key: KEYCODE or AnyNonModifier
modifiers: SETofKEYMASK or AnyModifier
grab-window: WINDOW
owner-events: BOOL
pointer-mode, keyboard-mode: {Synchronous, Asynchronous}
Errors: Window, Value, Access
This request establishes a passive grab on the keyboard. In the
future, if the specified key (which can itself be a modifier key) is
pressed when the specified modifier keys are down (and no other
modifier keys are down), and the KeyPress event would be generated in
grab-window or one of its inferiors, and these constraints are not
satisfied for any ancestor, then the keyboard is actively grabbed as
described in GrabKeyboard, the last-keyboard-grab time is set to the
time at which the key was pressed (as transmitted in the KeyPress
event), and the KeyPress event is reported. The interpretation of the
remaining arguments is as for GrabKeyboard. The active grab is
terminated automatically when the specified key has been released
(independent of the state of the modifier keys).
A modifiers of AnyModifier is equivalent to issuing the request for all
possible modifier combinations. A key of AnyNonModifier is equivalent
to issuing the request for all possible non-modifier key codes.
An Access error is generated if some other client has issued a GrabKey
with the same key combination on the same window. When using
AnyModifier or AnyNonModifier, the request fails completely (no grabs
are established) if there is a conflicting grab for any combination.
UngrabKey
key: KEYCODE or AnyNonModifier
modifiers: SETofKEYMASK or AnyModifier
grab-window: WINDOW
Errors: Window
Releases the key combination on the specified window if it was grabbed
by this client. A modifiers of AnyModifier is equivalent to issuing
the request for all possible modifier combinations. A key of
AnyNonModifier is equivalent to issuing the request for all possible
non-modifier key codes. Has no effect on an active grab.
AllowEvents
mode: {AsyncPointer, SyncPointer, ReplayPointer,
AsyncKeyboard, SyncKeyboard, ReplayKeyboard}
time: TIMESTAMP or CurrentTime
Errors: Value
Releases some queued events if the client has caused a device to
freeze. The request has no effect if the specified time is earlier
than the last-grab time of the most recent active grab for the client,
or if the specified time is later than the current server time.
For AsyncPointer, if the pointer is frozen by the client, pointer event
processing continues normally. If the pointer is frozen twice by the
client on behalf of two separate grabs, AsyncPointer "thaws" for both.
AsyncPointer has no effect if the pointer is not frozen by the client,
but the pointer need not be grabbed by the client.
For SyncPointer, if the pointer is frozen and actively grabbed by the
client, pointer event processing continues normally until the next
ButtonPress or ButtonRelease event is reported to the client, at which
time the pointer again appears to freeze. However if the reported
event causes the pointer grab to be released, then the pointer does not
freeze. SyncPointer has no effect if the pointer is not frozen by the
client, or if the pointer is not grabbed by the client.
For ReplayPointer, if the pointer is actively grabbed by the client and
is frozen as the result of an event having been sent to the client
(either from the activation of a GrabButton, or from a previous
AllowEvents with mode SyncPointer, but not from a GrabPointer), then
the pointer grab is released and that event is completely reprocessed,
but this time ignoring any passive grabs at or above (towards the root)
the grab-window of the grab just released. The request has no effect
if the pointer is not grabbed by the client, or if the pointer is not
frozen as the result of an event.
For AsyncKeyboard, if the keyboard is frozen by the client, keyboard
event processing continues normally. If the pointer is frozen twice by
the client on behalf of two separate grabs, AsyncPointer "thaws" for
both. AsyncKeyboard has no effect if the keyboard is not frozen by the
client, but the keyboard need not be grabbed by the client.
For SyncKeyboard, if the keyboard is frozen and actively grabbed by the
client, keyboard event processing continues normally until the next
KeyPress or KeyRelease event is reported to the client, at which time
the keyboard again appears to freeze. However if the reported event
causes the keyboard grab to be released, then the keyboard does not
freeze. SyncKeyboard has no effect if the keyboard is not frozen by
the client, or if the keyboard is not grabbed by the client.
For ReplayKeyboard, if the keyboard is actively grabbed by the client
and is frozen as the result of an event having been sent to the client
(either from the activation of a GrabKey, or from a previous
AllowEvents with mode SyncKeyboard, but not from a GrabKeyboard), then
the keyboard grab is released and that event is completely reprocessed,
but this time ignoring any passive grabs at or above (towards the root)
the grab-window of the grab just released. The request has no effect
if the keyboard is not grabbed by the client, or if the keyboard is not
frozen as the result of an event.
AsyncPointer, SyncPointer, and Replay Pointer have no effect on
processing of keyboard events. AsyncKeyboard, SyncKeyboard, and
ReplayKeyboard have no effect on processing of pointer events.
It is possible for both a pointer grab and a keyboard grab to be active
simultaneously (by the same or different clients). If a device is
frozen on behalf of either grab, no event processing is performed for
the device. It is possible for a single device to be frozen due to
both grabs. In this case, the freeze must be released on behalf of
both grabs before events can again be processed.
GrabServer
Disables processing of requests and close-downs on all other
connections (than the one this request arrived on).
UngrabServer
Restarts processing of requests and close-downs on other connections.
QueryPointer
window: WINDOW
=>
root: WINDOW
child: WINDOW or None
same-screen: BOOL
root-x, root-y, win-x, win-y: INT16
mask: SETofKEYBUTMASK
Errors: Window
The root window the pointer is currently on, and pointer coordinates
relative to the root's origin, are returned. If same-screen is False,
then the pointer is not on the same screen as the argument window, and
child is None and win-x and win-y are zero. If same-screen is True,
then win-x and win-y are the pointer coordinates relative to the
argument window's origin, and child is the child containing the
pointer, if any. The current state of the modifier keys and the
buttons are also returned.
GetMotionEvents
start, stop: TIMESTAMP or CurrentTime
window: WINDOW
=>
events: LISTofTIMECOORD
where
TIMECOORD: {x, y: CARD16
time: TIMESTAMP}
Error: Window
Returns all events in the motion history buffer that fall between the
specified start and stop times (inclusive) and that have coordinates
that lie within (including borders) the specified window at its present
placement. The x and y coordinates are reported relative to the origin
of the window.
TranslateCoordinates
src-window, dst-window: WINDOW
src-x, src-y: INT16
=>
same-screen: BOOL
child: WINDOW or None
dst-x, dst-y: INT16
Errors: Window
The src-x and src-y coordinates are taken relative to src-window's
origin, and returned as dst-x and dst-y coordinates relative to
dst-window's origin. If same-screen is False, then src-window and
dst-window are on different screens, and dst-x and dst-y are zero. If
the coordinates are contained in a mapped child of dst-window, then
that child is returned.
WarpPointer
src-window: WINDOW or None
dst-window: WINDOW
src-x, src-y: INT16
src-width, src-height: CARD16
dst-x, dst-y: INT16
Errors: Window
Moves the pointer to [dst-x, dst-y] relative to dst-window's origin.
If src-window is None, the move is independent of the current pointer
position, but if a window is specified, the move only takes place if
the pointer is currently contained in a visible portion of the
specified rectangle of the src-window.
The src-x and src-y coordinates are relative to src-window's origin.
If src-height is zero, it is replaced with the current height of
src-window minus src-y. If src-width is zero, it is replaced with the
current width of src-window minus src-x.
This request cannot be used to move the pointer outside the confine-to
window of an active pointer grab; an attempt will only move the pointer
as far as the closest edge of the confine-to window.
SetInputFocus
focus: WINDOW or PointerRoot or None
revert-to: {Parent, PointerRoot, None}
time: TIMESTAMP or CurrentTime
Errors: Window, Value
Changes the input focus and the last-focus-change time. The request
has no effect if the specified time is earlier than the current
last-focus-change time or is later than the current server time;
otherwise, the last-focus-change time is set to the specified time,
with CurrentTime replaced by the current server time.
If None is specified as the focus, all keyboard events are discarded
until a new focus window is set. In this case, the revert-to argument
is ignored.
If a window is specified as the focus, it becomes the keyboard's focus
window. If a generated keyboard event would normally be reported to
this window or one of its inferiors, the event is reported normally;
otherwise, the event is reported with respect to the focus window.
If PointerRoot is specified as the focus, the focus window is
dynamically taken to be the root window of whatever screen the pointer
is on at each keyboard event. In this case, the revert-to argument is
ignored.
This request generates FocusIn and FocusOut events.
If the focus window becomes not viewable, the new focus window depends
on the revert-to argument. If revert-to is Parent, the focus reverts
to the parent (or the closest viewable ancestor) and the new revert-to
value is take to be None. If revert-to is PointerRoot or None, the
focus reverts to that value. When the focus reverts, FocusIn and
FocusOut events are generated, but the last-focus-change time is not
affected.
GetInputFocus
=>
focus: WINDOW or PointerRoot or None
revert-to: {Parent, PointerRoot, None}
Returns the current focus state.
QueryKeymap
=>
keys: LISTofCARD8
Returns a bit vector for the keyboard; each one bit indicates that the
corresponding key is currently pressed. The vector is represented as
32 bytes. Byte N (from 0) contains the bits for keys 8N to 8N+7, with
the least significant bit in the byte representing key 8N.
OpenFont
fid: FONT
name: STRING8
Errors: IDChoice, Name, Alloc
Loads the specified font, if necessary, and associates identifier fid
with it. The font can be used as a source for any drawable. The font
name should use the ASCII encoding, and upper/lower case does not
matter.
CloseFont
font: FONT
Errors: Font
Deletes the association between the resource id and the font. The font
itself will be freed when no other resource references it.
∂01-Jun-87 0530 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 5 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:29:45 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:28-EDT
Date: Mon, 1 Jun 87 08:28 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 5 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082843.0.RWS@KILLINGTON.LCS.MIT.EDU>
PolyArc
drawable: DRAWABLE
gc: GCONTEXT
arcs: LISTofARC
Errors: Drawable, GContext, Match
Draws circular or elliptical arcs. Each arc is specified by a
rectangle and two angles. The x and y coordinates are relative to the
origin of the drawable, and define the upper left corner of the
rectangle. The center of the circle or ellipse is the center of the
rectangle, and the major and minor axes are specified by the width and
height, respectively. The angles are signed integers in degrees scaled
by 64, with positive indicating counterclockwise motion and negative
indicating clockwise motion. The start of the arc is specified by
angle1 relative to the three-oclock position from the center, and the
path and extent of the arc is specified by angle2 relative to the start
of the arc. If the magnitude of angle2 is greater than 360 degrees, it
is truncated to 360 degrees.
The arcs are drawn in the order listed. If the last point in one arc
coincides with the first point in the following arc, the two arcs will
join correctly. If the first point in the first arc coincides with the
last point in the last arc, the two arcs will join correctly. For any
given arc, no pixel is drawn more than once. If two arcs join
correctly and the line-width is greater than zero and the arcs
intersect, no pixel is drawn more than once. Otherwise, the
intersecting pixels of intersecting arcs are drawn multiple times.
Specifying an arc with one endpoint and a clockwise extent draws the
same pixels as specifying the other endpoint and an equivalent
counterclockwise extent, except as it affects joins.
By specifying one axis to be zero, a horizontal or vertical line can be
drawn.
Angles are computed based solely on the coordinate system, ignoring the
aspect ratio.
GC components: alu-function, plane-mask, line-width, line-style,
cap-style, join-style, fill-style, subwindow-mode, clip-x-origin,
clip-y-origin, clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dash-list
FillPoly
drawable: DRAWABLE
gc: GCONTEXT
shape: {Complex, Nonconvex, Convex}
coordinate-mode: {Origin, Previous}
points: LISTofPOINT
Errors: Drawable, GContext, Match, Value
Fills the region closed by the specified path. The path is closed
automatically if the last point in the list does not coincide with the
first point. No pixel of the region is drawn more than once.
The first point is always relative to the drawable's origin; the rest
are relative either to that origin or the previous point, depending on
the coordinate-mode.
The shape parameter may be used by the server to improve performance.
Complex means the path may self-intersect.
Nonconvex means the path does not self-intersect, but the shape is not
wholly convex. If known by the client, specifying Nonconvex over
Complex may improve performance. If Nonconvex is specified for a
self-intersecting path, the graphics results are undefined.
Convex means the path is wholly convex. If known by the client,
specifying Convex can improve performance. If Convex is specified for
a path that is not convex, the graphics results are undefined.
GC components: alu-function, plane-mask, fill-style, fill-rule,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PolyFillRectangle
drawable: DRAWABLE
gc: GCONTEXT
rectangles: LISTofRECTANGLE
Errors: Drawable, GContext, Match
Fills the specified rectangles. The x and y coordinates of each
rectangle are relative to the drawable's origin, and define the upper
left corner of the rectangle.
The rectangles are drawn in the order listed. For any given rectangle,
no pixel is drawn more than once. If rectangles intersect, the
intersecting pixels are drawn multiple times.
GC components: alu-function, plane-mask, fill-style, fill-rule,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PolyFillArc
drawable: DRAWABLE
gc: GCONTEXT
arcs: LISTofARC
Errors: Drawable, GContext, Match
For each arc, fills the region closed by the specified arc and one or
two line segments, depending on the arc-mode. For Chord, the single
line segment joining the endpoints of the arc is used. For PieSlice,
the two line segments joining the endpoints of the arc with the center
point are used. The arcs are as specified in the PolyArc request.
The arcs are filled in the order listed. For any given arc, no pixel
is drawn more than once. If regions intersect, the intersecting pixels
are drawn multiple times.
GC components: alu-function, plane-mask, fill-style, fill-rule,
arc-mode, subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PutImage
drawable: DRAWABLE
gc: GCONTEXT
depth: CARD8
width, height: CARD16
dst-x, dst-y: INT16
left-pad: CARD8
format: {Bitmap, XYPixmap, ZPixmap}
bits: <bits>
Errors: Drawable, GContext, Match, Value, Alloc
Combines an image with a rectangle of the drawable. The dst-x and
dst-y coordinates are relative to the drawable's origin.
If Bitmap format is used, then depth must be one (else a Match error)
and the image must be in XYFormat. The foreground pixel in gc defines
the source for one bits in the image, and the background pixel defines
the source for the zero bits.
For XYPixmap and ZPixmap, depth must match the depth of drawable (else
a Match error). For XYPixmap, the image must be sent in XYFormat. For
ZPixmap, the image must be sent in the ZFormat defined for the given
depth.
The left-pad must be zero for ZPixmap format. For Bitmap and XYPixmap
format, left-pad must be less than bitmap-format-scanline-pad (as given
in the server connection setup info). The first left-pad bits in every
scanline are to be ignored by the server; the actual image begins that
many bits into the data. The width argument defines the width of the
actual image, and does not include left-pad.
GC components: alu-function, plane-mask, subwindow-mode, clip-x-origin,
clip-y-origin, clip-mask
GC mode-dependent components: foreground, background
GetImage
drawable: DRAWABLE
x, y: INT16
width, height: CARD16
plane-mask: CARD32
format: {XYFormat, ZFormat}
=>
depth: CARD8
visual: VISUALID or None
bits: <bits>
Errors: Drawable, Value, Match
Returns the contents of the given rectangle of the drawable in the
given format. The x and y coordinates are relative to the drawable's
origin, and define the upper left corner of the rectangle. If XYFormat
is specified, only the bit planes specified in plane-mask are
transmitted. If ZFormat is specified, then bits in all planes not
specified in plane-mask transmitted as zero. The returned depth
specifies the number of bits per pixel of the image. If the drawable
is a window, its visual type is returned; if the drawable is a pixmap,
the visual is None.
If the drawable is a window, the window must be mapped, and it must be
the case that, if there were no inferiors or overlapping windows, the
specified rectangle of the window would be fully visible on the screen
(else a Match error). The returned image will include any visible
portions of inferiors or overlapping windows contained in the
rectangle, but if these windows are of different depth than the
specified window, the contents returned for them are not defined by the
core protocol.
PolyText8
drawable: DRAWABLE
gc: GCONTEXT
x, y: INT16
items: LISTofTEXTITEM8
where
TEXTITEM8: TEXTELT8 or FONT
TEXTELT8: [delta: INT8
string: STRING8]
Errors: Drawable, GContext, Match, Font
The x and y coordinates are relative to drawable's origin, and specify
the baseline starting position (the initial character origin). Each
text item is processed in turn. A font item causes the font to be
stored in gc, and to be used for subsequent text; switching among fonts
with differing draw-directions is permitted. A text element delta
specifies an additional change in the position along the x axis before
the string is drawn; the delta is always added to the character origin
(not added or subtracted based on the draw-direction of the current
font). Each character image, as defined by the font in gc, is treated
as an additional mask for a fill operation on the drawable.
All contained FONTs are always transmitted most significant byte first.
If a Font error is generated for an item, the previous items may have
been drawn.
For fonts defined with two-byte matrix indexing, each STRING8 byte is
interpreted as a byte2 value of a CHAR2B with a byte1 value of zero.
GC components: alu-function, plane-mask, fill-style, font,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PolyText16
drawable: DRAWABLE
gc: GCONTEXT
x, y: INT16
items: LISTofTEXTITEM16
where
TEXTITEM16: TEXTELT16 or FONT
TEXTELT16: [delta-x: INT8
string: STRING16]
Errors: Drawable, GContext, Match, Font
Just like PolyText8, except two-byte (or 16-bit) characters are used.
For fonts defined with linear indexing rather than two-byte matrix
indexing, the server will interpret each CHAR2B as a 16-bit number that
has been transmitted most significant byte first (i.e., byte1 of the
CHAR2B is taken as the most significant byte).
ImageText8
drawable: DRAWABLE
gc: GCONTEXT
x, y: INT16
string: STRING8
Errors: Drawable, GContext, Match
The x and y coordinates are relative to drawable's origin, and specify
the baseline starting position (the initial character origin). The
effect is to first fill a destination rectangle with the background
pixel defined in gc, and then paint the text with the foreground pixel.
The upper left corner of the filled rectangle is at
[x + overall-left, y - font-ascent]
the width is
overall-right - overall-left
and the height is
font-ascent + font-descent
where overall-left, overall-right, font-ascent, and font-descent are as
would be returned by a QueryTextExtents call using gc and string.
The alu-function and fill-style defined in gc are ignored for this
request; the effective alu-function is Copy and the effective
fill-style Solid.
For fonts defined with two-byte matrix indexing, each STRING8 byte is
interpreted as a byte2 value of a CHAR2B with a byte1 value of zero.
GC components: plane-mask, foreground, background, font,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
ImageText16
drawable: DRAWABLE
gc: GCONTEXT
x, y: INT16
string: STRING16
Errors: Drawable, GContext, Match
Just like ImageText8, except two-byte (or 16-bit) characters are used.
For fonts defined with linear indexing rather than two-byte matrix
indexing, the server will interpret each CHAR2B as a 16-bit number that
has been transmitted most significant byte first (i.e., byte1 of the
CHAR2B is taken as the most significant byte).
CreateColormap
mid: COLORMAP
visual: VISUALID
window: WINDOW
alloc: {None, All}
Errors: IDChoice, Window, Value, Match, Alloc
Creates a colormap of the specified visual type for the screen on which
the window resides, and associates the identifier mid with it. The
visual type must be one supported by the screen, and cannot be of class
TrueColor (else a Match error). The initial values of the colormap
entries are undefined for classes GrayScale, PseudoColor, and
DirectColor; for StaticGray, StaticColor, and TrueColor, the entries
will have defined values, but those values are specific to the visual
and are not defined by the core protocol. For StaticGray, StaticColor,
and TrueColor, alloc must be specified as None (else a Match error).
For the other classes, if alloc is None, the colormap initially has no
allocated entries, and clients can allocate entries. If alloc is All,
then the entire colormap is "allocated" writable, but entries cannot be
freed with FreeColors, and no relationships among entries is defined;
the client must understand whether the colormap is GrayScale,
PseudoColor, or DirectColor to know how to store into entries.
FreeColormap
cmap: COLORMAP
Errors: Colormap
Deletes the association between the resource id and the colormap. If
the colormap is an installed map for a screen, it is uninstalled (see
UninstallColormap). If the colormap is defined as the colormap for a
window (via CreateWindow or ChangeWindowAttributes), the colormap for
the window is changed to None, and a ColormapNotify event is generated.
The colors displayed for a window with a colormap of None are not
defined by the protocol.
Has no effect on a default colormap for a screen.
CopyColormapAndFree
mid, src-cmap: COLORMAP
Errors: Colormap, Alloc
Creates a colormap for the same screen as src-cmap, and associates
identifier mid with it. Moves all of the client's existing allocations
from src-cmap to the new colormap, and frees those entries in src-cmap.
Values in other entries in the new colormap are undefined.
InstallColormap
cmap: COLORMAP
Errors: Colormap
Makes this colormap an installed map for its screen. All windows
associated with this colormap immediately display with true colors. As
a side-effect, previously installed colormaps may be uninstalled, and
other windows may display with false colors. Which colormaps get
uninstalled is server dependent, except that it is guaranteed that the
M-1 most recently client-installed colormaps will not be uninstalled,
where M is the min-installed-maps specified for the screen in the
connection setup.
If cmap is not already an installed map, a ColormapNotify event is
generated on every window having cmap as an attribute. If a colormap
is uninstalled as a result of the install, a ColormapNotify event is
generated on every window having that colormap as an attribute.
Initially only the default colormap for a screen is installed.
UninstallColormap
cmap: COLORMAP
Errors: Colormap
If cmap is an installed map for its screen, one or more colormaps are
installed in its place; the choice is server dependent, except that if
the screen's default colormap is not installed and can be installed
(without forcing other colormaps out), then the default colormap is
used.
If cmap is an installed map, a ColormapNotify event is generated on
every window having this colormap as an attribute. If a colormap is
installed as a result of the uninstall, a ColormapNotify event is
generated on every window having that colormap as an attribute.
ListInstalledColormaps
window: WINDOW
=>
cmaps: LISTofCOLORMAP
Errors: Window
Returns a list of the currently installed colormaps for the screen of
the specified window.
AllocColor
cmap: COLORMAP
red, green, blue: CARD16
=>
pixel: CARD32
red, green, blue: CARD16
Errors: Colormap, Alloc
Allocates a read-only colormap entry corresponding to the closest RGB
values provided by the hardware. Returns the pixel and the RGB values
actually used.
AllocNamedColor
cmap: COLORMAP
name: STRING8
=>
pixel: CARD32
exact-red, exact-green, exact-blue: CARD16
screen-red, screen-green, screen-blue: CARD16
Errors: Colormap, Name, Alloc
Looks up the named color with respect to the screen associated with the
colormap, then does an AllocColor on cmap. The name should use the
ASCII encoding, and upper/lower case does not matter. The exact RGB
values specify the "true" values for the color, and the screen values
specify the values actually used in the colormap.
AllocColorCells
cmap: COLORMAP
colors, planes: CARD16
contiguous: BOOL
=>
pixels, masks: LISTofCARD32
Errors: Colormap, Value, Alloc
The number of colors must be positive, the number of planes
non-negative. If C colors and P planes are requested, then C pixels
and P masks are returned. No mask will have any bits in common with
any other mask, or with any of the pixels. By ORing together masks and
pixels, C*(2↑P) distinct pixels can be produced; all of these are
allocated writable by the request. For GrayScale or PseudoColor, each
mask will have exactly one bit, and for DirectColor each will have
exactly three bits. If contiguous is True, then if all masks are ORed
together, a single contiguous set of bits will be formed for GrayScale
or PseudoColor, and three contiguous sets of bits (one within each
pixel subfield) for DirectColor. The RGB values of the allocated
entries are undefined.
AllocColorPlanes
cmap: COLORMAP
colors, reds, greens, blues: CARD16
contiguous: BOOL
=>
pixels: LISTofCARD32
red-mask, green-mask, blue-mask: CARD32
Errors; Colormap, Value, Alloc
The number of colors must be positive, the reds, greens, and blues
non-negative. If C colors, R reds, G greens, and B blues are
requested, then C pixels are returned, and the masks have R, G, and B
bits set respectively. If contiguous is True, then each mask will have
a contiguous set of bits. No mask will have any bits in common with
any other mask, or with any of the pixels. For DirectColor, each mask
will lie within the corresponding pixel subfield. By ORing together
subsets of masks with pixels, C*(2↑(R+G+B)) distinct pixels can be
produced; all of these are allocated by the request. The initial RGB
values of the allocated entries are undefined. In the colormap there
are only C*(2↑R) independent red entries, C*(2↑G) independent green
entries, and C*(2↑B) independent blue entries. This is true even for
PseudoColor. When the colormap entry for a pixel value is changed
using StoreColors or StoreNamedColor, the pixel is decomposed according
to the masks and the corresponding independent entries are updated.
FreeColors
cmap: COLORMAP
pixels: LISTofCARD32
plane-mask: CARD32
Errors: Colormap, Access, Value
The plane-mask should not have any bits in common with any of the
pixels. The set of all pixels is produced by ORing together subsets of
plane-mask with the pixels. The request frees all of these pixels.
Note that freeing an individual pixel obtained from AllocColorPlanes
may not actually allow it to be reused until all of its "related"
pixels are also freed.
All specified pixels that are allocated by the client in cmap are
freed, even if one or more pixels produce an error. A Value error is
generated if a specified pixel is not a valid index into cmap, and an
Access error is generated if a specified pixel is not allocated by the
client (i.e., is unallocated or is only allocated by another client).
If more than one pixel is in error, which one is reported is arbitrary.
StoreColors
cmap: COLORMAP
items: LISTofCOLORITEM
where
COLORITEM: [pixel: CARD32
do-red, do-green, do-blue: BOOL
red, green, blue: CARD16]
Errors: Colormap, Access, Value
Changes the colormap entries of the specified pixels. The do-red,
do-green, and do-blue fields indicate which components should actually
be changed. If the colormap is an installed map for its screen, the
changes are visible immediately.
All specified pixels that are allocated writable in cmap (by any
client) are changed, even if one or more pixels produce an error. A
Value error is generated if a specified pixel is not a valid index into
cmap, and an Access error is generated if a specified pixel is
unallocated or is allocated read-only. If more than one pixel is in
error, which one is reported is arbitrary.
StoreNamedColor
cmap: COLORMAP
pixel: CARD32
name: STRING8
do-red, do-green, do-blue: BOOL
Errors: Colormap, Name, Access, Value
Looks up the named color with respect to the screen associated with
cmap, then does a StoreColors in cmap. The name should use the ASCII
encoding, and upper/lower case does not matter.
QueryColors
cmap: COLORMAP
pixels: LISTofCARD32
=>
colors: LISTofRGB
where
RGB: [red, green, blue: CARD16]
Errors: Colormap, Value
Returns the color values stored in cmap for the specified pixels. The
values returned for an unallocated entry are undefined. A Value error
is generated if a pixel is not a valid index into cmap. If more than
one pixel is in error, which one is reported is arbitrary.
LookupColor
cmap: COLORMAP
name: STRING8
=>
exact-red, exact-green, exact-blue: CARD16
screen-red, screen-green, screen-blue: CARD16
Errors: Colormap, Name
Looks up the string name of a color with respect to the screen
associated with cmap, and returns both the exact the color values and
the closest values provided by the hardware. The name should use the
ASCII encoding, and upper/lower case does not matter.
CreateCursor
cid: CURSOR
source: PIXMAP
mask: PIXMAP or None
fore-red, fore-green, fore-blue: CARD16
back-red, back-green, back-blue: CARD16
x, y: CARD16
Errors: IDChoice, Bitmap, Match, Value, Alloc
Creates a cursor and associates identifier cid with it. Foreground and
background RGB values must be specified, even if the server only has a
monochrome screen. The foreground is used for the one bits in the
source, and the background is used for the zero bits. Both source and
mask (if specified) must have depth one (else a Match error), but can
have any root. The mask pixmap defines the shape of the cursor; that
is, the one bits in the mask define which source pixels will be
displayed. If no mask is given, all pixels of the source are
displayed. The mask, if present, must be the same size as source (else
a Match error). The x and y coordinates define the hotspot, relative
to the source's origin, and must be a point within the source (else a
Match error).
The components of the cursor may be transformed arbitrarily to meet
display limitations.
The pixmaps can be freed immediately if no further explicit references
to them are to be made.
Subsequent drawing in the source or mask pixmap has an undefined effect
on the cursor; the server might or might not make a copy of the pixmap.
CreateGlyphCursor
cid: CURSOR
source-font: FONT
mask-font: FONT or None
source-char, mask-char: CARD16
fore-red, fore-green, fore-blue: CARD16
back-red, back-green, back-blue: CARD16
Errors: IDChoice, Font, Value, Alloc
Similar to CreateCursor, but the source and mask bitmaps are obtained
from the specified font glyphs. The mask font and character are
optional. The origin of the source glyph defines the hotspot, and the
mask is positioned such that the origins are coincident. The source
and mask need not have the same bounding box metrics. If no mask is
given, all pixels of the source are displayed. Note that source-char
and mask-char are CARD16 (not CHAR2B); for two-byte matrix fonts, the
16-bit value should be formed with byte1 in the most significant byte
and byte2 in the least significant byte.
FreeCursor
cursor: CURSOR
Errors: Cursor
Deletes the association between the resource id and the cursor. The
cursor storage will be freed when no other resource references it.
RecolorCursor
cursor: CURSOR
fore-red, fore-green, fore-blue: CARD16
back-red, back-green, back-blue: CARD16
Errors: Cursor
Changes the color of a cursor. If the cursor is being displayed on a
screen, the change is visible immediately.
QueryBestSize
class: {Cursor, Tile, Stipple}
drawable: DRAWABLE
width, height: CARD16
=>
width, height: CARD16
Errors: Drawable, Value, Match
Returns the "best" size that is "closest" to the argument size. For
Cursor, this is the largest size that can be fully displayed. For
Tile, this is the size that can be tiled "fastest". For Stipple, this
is the size that can be stippled "fastest".
For Cursor, the drawable indicates the desired screen. For Tile and
Stipple, the drawable indicates screen, and also possibly window class
and depth; an InputOnly window cannot be used as the drawable for Tile
or Stipple (else a Match error).
QueryExtension
name: STRING8
=>
present: BOOL
major-opcode: CARD8
first-event: CARD8
first-error: CARD8
Determines if the named extension is present. If so, the major opcode
for the extension is returned, if it has one, otherwise zero is
returned. Any minor opcode and the request formats are specific to the
extension. If the extension involves additional event types, the base
event type code is returned, otherwise zero is returned. The format of
the events is specific to the extension. If the extension involves
additional error codes, the base error code is returned, otherwise
zero is returned. The format of additional data in the errors is
specific to the extension.
The extension name should be in the ASCII encoding, and upper/lower
case matters.
ListExtensions
=>
names: LISTofSTRING8
Returns a list of all extensions supported by the server.
SetKeyboardMapping
map: LISTofCARD8
=>
status: {Success, Busy}
Errors: Value
Sets the mapping of the keyboard. Elements of the list are indexed
starting from one. The list must be of length 255. The index is a
"core" keycode, and the element of the list defines the "effective"
keycode.
A zero element disables a key, no elements can have values 1 through 7,
and no two elements (with index larger than 7) can have the same
non-zero value. If the keyboard does not really generate a given
keycode, specifying a non-zero value for that core keycode has no
effect.
Elements 6 and 7 of the map must always be zero. The first five
elements are special: they specify the keycodes (if any) that
correspond to the Mod1 through Mod5 modifiers. Setting one of these
entries to zero disables use of that modifier bit. No two of the first
five elements can have the same non-zero value.
A server can impose restrictions on how keyboards get remapped, e.g.,
if certain keys do not generate up transitions in hardware.
If any of the keys or modifiers to be altered are currently in the down
state, the status reply is Busy and the mapping is not changed.
GetKeyboardMapping
=>
map: LISTofCARD8
Errors: Value
Returns the current mapping of the keyboard. Elements of the list are
indexed starting from one. The length of the list is 255.
The nominal mapping for a keyboard is almost the identity mapping,
except that map[i]=0 for keycodes that have no corresponding physical
key, and the first five entries indicate the keycodes (if any)
corresponding to the Mod1 through Mod5 modifier bits.
ChangeKeyboardControl
value-mask: BITMASK
value-list: LISTofVALUE
Errors: Match, Value
Controls various aspects of the keyboard. The value-mask and
value-list specify which controls are to be changed. The possible
values are:
key-click-percent: INT8
bell-percent: INT8
bell-pitch: INT16
bell-duration: INT16
led: CARD8
led-mode: {On, Off}
key: KEYCODE
auto-repeat-mode: {On, Off, Default}
Key-click-percent sets the volume for key clicks between 0 (off) and
100 (loud) inclusive, if possible. Setting to -1 restores the default.
Other negative values generate a Value error.
Bell-percent sets the base volume for the bell between 0 (off) and 100
(loud) inclusive, if possible. Setting to -1 restores the default.
Other negative values generate a Value error.
Bell-pitch sets the pitch (specified in Hz) of the bell, if possible.
Setting to -1 restores the default. Other negative values generate a
Value error.
Bell-duration sets the duration (specified in milliseconds) of the
bell, if possible. Setting to -1 restores the default. Other negative
values generate a Value error.
If both led-mode and led are specified, then the state of that LED is
changed, if possible. If only led-mode is specified, then the state of
all LEDs are changed, if possible. At most 32 LEDs are supported,
numbered from one. It is a Match error if an led is specified without
an led-mode.
If both auto-repeat-mode and key are specified, then the auto-repeat
mode of that key is changed, if possible. If only auto-repeat-mode is
specified, then the global auto-repeat mode for the entire keyboard is
changed, if possible, without affecting the per-key settings. It is a
Match error if a key is specified without an auto-repeat-mode.
A bell generator connected with the console but not directly on the
keyboard is treated as if it were part of the keyboard.
The order in which controls are verified and altered is server
dependent. If an error is generated, a subset of the controls may have
been altered.
GetKeyboardControl
=>
key-click-percent: CARD8
bell-percent: CARD8
bell-pitch: CARD16
bell-duration: CARD16
led-mask: CARD32
global-auto-repeat: {On, Off}
auto-repeats: LISTofCARD8
Errors: Match
Returns the current control values for the keyboard. For the LEDs, the
least significant bit of led-mask corresponds to LED one, and each one
bit in led-mask indicates an LED that is lit. Auto-repeats is a bit
vector; each one bit indicates that auto-repeat is enabled for the
corresponding key. The vector is represented as 32 bytes. Byte N
(from 0) contains the bits for keys 8N to 8N+7, with the least
significant bit in the byte representing key 8N.
Bell
percent: INT8
Errors: Match, Value
Rings the bell on the keyboard at the specified volume relative to the
base volume for the keyboard, if possible. Percent, which can range
from -100 to 100 inclusive, is added to the base volume, and the sum
limited to the range 0 to 100 inclusive.
∂01-Jun-87 0527 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 1 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:27:21 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:26-EDT
Date: Mon, 1 Jun 87 08:26 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 1 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082645.6.RWS@KILLINGTON.LCS.MIT.EDU>
X WINDOW SYSTEM PROTOCOL, VERSION 11
Alpha Update
April 1987
Copyright (c) 1986, 1987 Massachusetts Institute of Technology
X Window System is a trademark of M.I.T.
Permission to use, copy, modify, and distribute this document for any purpose
and without fee is hereby granted, provided that the above copyright notice
appear in all copies and that both that copyright notice and this permission
notice are retained, and that the name of M.I.T. not be used in advertising or
publicity pertaining to this document without specific, written prior
permission. M.I.T. makes no representations about the suitability of this
document or the protocol defined in this document for any purpose. It is
provided "as is" without express or implied warranty.
Author: Robert W. Scheifler
Laboratory for Computer Science
545 Technology Square, Room 418
Cambridge, MA 02139
Contributors:
Dave Carver (Digital HPW)
Branko Gerovac (Digital HPW)
Jim Gettys (MIT/Project Athena, Digital)
Phil Karlton (Digital WSL)
Scott McGregor (Digital SSG)
Ram Rao (Digital UEG)
David Rosenthal (Sun)
Dave Winchell (Digital UEG)
Implementors of initial server who provided useful input:
Susan Angebranndt (Digital)
Raymond Drewry (Digital)
Todd Newman (Digital)
Invited reviewers who provided useful input:
Andrew Cherenson (Berkeley)
Burns Fisher (Digital)
Dan Garfinkel (HP)
Leo Hourvitz (Next)
Brock Krizan (HP)
David Laidlaw (Stellar)
Dave Mellinger (Interleaf)
Ron Newman (MIT)
John Ousterhout (Berkeley)
Andrew Palay (ITC CMU)
Ralph Swick (MIT)
Craig Taylor (Sun)
Jeffery Vroom (Stellar)
This document does not attempt to provide the rationale or pragmatics required
to fully understand the protocol or to place it in perspective within a
complete system. Knowledge of X Version 10 will certainly aid in
understanding this document.
The protocol contains many management mechanisms that are not intended for
normal applications. Not all mechanisms are needed to build a particular user
interface. It is important to keep in mind that the protocol is intended to
provide mechanism, not policy.
This document does not attempt to define precise formats or bit encodings.
-------------------------------------------------------------------------------
SECTION 1. TERMINOLOGY
Access control list
X maintains a list of hosts from which client programs may be run. By
default, only programs on the local host may use the display, plus any
hosts specified in an initial list read by the server. This "access
control list" can be changed by clients on the local host. Some server
implementations may also implement other authorization mechanisms.
Active grab
A grab is "active" when the pointer or keyboard is actually owned by
the single grabbing client.
Ancestors
If W is an inferior of A, then A is an "ancestor" of W.
Atom
An "atom" is a unique id corresponding to a string name. Atoms are
used to identify properties, types, and selections.
Backing store
When a server maintains the contents of a window, the off-screen saved
pixels are known as a "backing store".
Bit gravity
When a window is resized, the contents of the window are not
necessarily discarded. It is possible to request the server (though no
guarantees are made) to relocate the previous contents to some region
of the window. This attraction of window contents for some location of
a window is known as "bit gravity".
Bitmap
A "bitmap" is a pixmap of depth one.
Button grabbing
Buttons on the pointer may be passively "grabbed" by a client. When
the button is pressed, the pointer is then actively grabbed by the
client.
Byte order
For image (pixmap/bitmap) data, byte order is defined by the server,
and clients with different native byte ordering must swap bytes as
necessary. For all other parts of the protocol, the byte order is
defined by the client, and the server swaps bytes as necessary.
Children
The "children" of a window are its first-level subwindows.
Client
An application program connects to the window system server by some
interprocess communication (IPC) path, such as a TCP connection or a
shared memory buffer. This program is referred to as a "client" of the
window system server. More precisely, the client is the IPC path
itself; a program with multiple paths open to the server is viewed as
multiple clients by the protocol. Resource lifetimes are controlled by
connection lifetimes, not by program lifetimes.
Clipping regions
In a graphics context, a bitmap or list of rectangles can be specified
to restrict output to a particular region of the window. The image
defined by the bitmap or rectangles is called a "clipping region".
Color cell
An entry in a colormap is known as a "color cell". An entry contains
three values specifying red, green and blue intensities. These values
are always viewed as 16 bit unsigned numbers, with zero being minimum
intensity. The values are scaled by the server to match the display
hardware. The components of a cell are coincident with components of
other cells in DirectColor and TrueColor colormaps.
Colormap
A "colormap" consists of a set of color cells. A pixel value indexes
the color map to produce intensities to be displayed. Depending on
hardware limitations, one or more colormaps may be installed at one
time, such that windows associated with those maps display with true
colors.
Connection
The IPC path between the server and client program is known as a
"connection". A client program typically (but not necessarily) has one
connection to the server over which requests and events are sent.
Containment
A window "contains" the pointer if the window is viewable and the
hotspot of the cursor is within a visible region of the window or a
visible region of one of its inferiors. The border of the window is
included as part of the window for containment. The pointer is "in" a
window if the window contains the pointer but no inferior contains the
pointer.
Coordinate system
The coordinate system has X horizontal and Y vertical, with the origin
[0, 0] at the upper left. Coordinates are discrete, and in terms of
pixels. Each window and pixmap has its own coordinate system. For a
window, the origin is at the inside upper left, inside the border.
Cursor
A "cursor" is the visible shape of the pointer on a screen. It
consists of a hot spot, a source bitmap, a shape bitmap, and a pair of
colors. The cursor defined for a window controls the visible
appearance when the pointer is in that window.
Depth
The "depth" of a window or pixmap is number of bits per pixel it has.
The depth of a gcontext is the depth of the root of the gcontext.
Device
Keyboards, mice, tablets, track-balls, button boxes, etc. are all
collectively known as input "devices". The core protocol only deals
with two devices, "the keyboard" and "the pointer".
Drawable
Both windows and pixmaps may be used as sources and destinations in
graphics operations. These are collectively known as "drawables".
However, an InputOnly window cannot be used as a source or destination
in a graphics operation.
Event
Clients are informed of information asynchronously via "events". These
events may be either asynchronously generated from devices, or
generated as side effects of client requests. Events are grouped into
types; events are never sent to a client by the server unless the
client has specificially asked to be informed of that type of event,
but other clients can force events to be sent to other clients. Events
are typically reported relative to a window.
Event mask
Events are requested relative to a window. The set of event types a
client requests relative to a window described using an "event mask".
Event sychronization
There are certain race conditions possible when demultiplexing device
events to clients (in particular deciding where pointer and keyboard
events should be sent when in the middle of window management
operations). The event synchronization mechanism allows synchronous
processing of device events.
Event propagation
Device-related events "propagate" from the source window to ancestor
windows until some client has expressed interest in handling that type
of event, or until the event is discarded explicitly.
Event source
The smallest window containing the pointer is the "source" of a device
related event.
Exposure event
Servers do not guarantee to preserve the contents of windows when
windows are obscured or reconfigured. "Exposure" events are sent to
clients to inform them when contents of regions of windows have been
lost.
Extension
Named "extensions" to the core protocol can be defined to extend the
system. Extension to output requests, resources, and event types are
all possible, and expected.
Font
A "font" is an array of glyphs (typically characters). The protocol
does no translation or interpretation of character sets. The client
simply indicates values used to index the glyph array. A font contains
additional metric information to determine inter-glyph and inter-line
spacing.
Glyph
A "glyph" is an image, typically of a character, in a font.
Grab
Keyboard keys, the keyboard, pointer buttons, the pointer, and the
server can be "grabbed" for exclusive use by a client. In general,
these facilities are not intended to be used by normal applications,
but are intended for various input and window managers to implement
various styles of user interfaces.
Graphics context
Various information for graphics output is stored in "GC"'s, such as
foreground pixel, background pixel, line width, clipping region, etc.
Hotspot
A cursor has an associated "hot spot" which defines a point in the
cursor that corresponds to the coordinates reported for the pointer.
Identifier
Each resource has an "identifier", a unique value associated with it
that clients use to name the resource. An identifier can be used over
any connection to name the resource.
Inferiors
The "inferiors" of a window are all of the subwindows nested below it:
the children, the children's children, etc.
Input focus
The "input focus" is nominally where keyboard input goes. Keyboard
events are by default sent to the client expressing interest on the
window the pointer is in. This is said to be a "real estate driven"
input focus. It is also possible to attach the keyboard input to a
specific window; events will then be sent to the appropriate client
independent of the pointer position.
Input manager
Control over keyboard input is typically provided by an "input manager"
client.
InputOnly window
A window that cannot be used for graphics requests. InputOnly windows
are "invisible", and can be used to control such things as cursors,
input event generation, and grabbing.
InputOutput window
The "normal" kind of opaque window, used for both input and output.
Key grabbing
Keys on the keyboard may be passively "grabbed" by a client. When the
key is pressed, the keyboard is then actively grabbed by the client.
Keyboard grabbing
A client can actively "grab" control of the keyboard, and key events
will be sent to that client rather than the client the events would
normally have been sent to.
Mapping
A window is said to be "mapped" if a map call has been performed on it.
Unmapped windows are never viewable or visible.
Modifier keys
Shift, Control, Meta, Super, Hyper, ALT, Compose, Apple, CapsLock,
ShiftLock, and similar keys are called "modifier" keys.
Obscures
Window A "obscures" window B if both are viewable InputOutput windows
and A is higher in the global stacking order, and the rectangle defined
by the outside edges of A intersects the rectangle defined by the
outside edges of B. Note the (fine) distinction with "occludes". Also
note that window borders are included in the calculation.
Occludes
Window A "occludes" window B if both are mapped and A is higher in the
global stacking order, and the rectangle defined by the outside edges
of A intersects the rectangle defined by the outside edges of B. Note
the (fine) distinction with "obscures". Also note that window borders
are included in the calculation.
Padding
Some padding bytes are inserted in the data stream to maintain
alignment of the protocol requests on natural boundaries. This
increases ease of portability to some machine architectures.
Parent window
If C is a child of P, then P is the "parent" of C.
Passive grab
Grabbing a key or button is a "passive" grab. The grab activates when
the key or button is actually pressed.
Pixel value
A "pixel" is an N-bit value, where N is the number of bit planes used
in a particular window or pixmap. For a window, a pixel value indexes
a colormap to derive an actual color to be displayed.
Pixmap
A "pixmap" is a three dimensional array of bits. A pixmap is normally
thought of as a two dimensional array of pixels, where each pixel can
be a value from 0 to (2↑N)-1, where N is the depth (z axis) of the
pixmap. A pixmap can also be thought of as a stack of N bitmaps.
Plane mask
Graphics operations can be restricted to only affect a subset of bit
planes of a destination. A "plane mask" is a bit mask describing which
planes are to be modified, and is stored in a graphics context.
Pointer
The "pointer" is the pointing device attached to the cursor, and
tracked on the screens.
Pointer grabbing
A client can actively "grab" control of the pointer, and button and
motion events will be sent to that client rather than the client the
events would normally have been sent to.
Pointing device
A "pointing device" is typically a mouse or tablet, or some other
device with effective dimensional motion. There is only one visible
cursor is defined by the core protocol, and it tracks whatever pointing
device is attached as the pointer.
Property
Windows may have associated "properties", consisting of a name, a type,
a data format, and some data. The protocol places no interpretation on
properties, they are intended as a general-purpose naming mechanism for
clients. For example, clients might share information such as resize
hints, program names, and icon formats with a window manager via
properties.
Property list
The "property list" of a window is the list of properties that have
been defined for the window.
Redirecting control
Window managers (or client programs) may wish to enforce window layout
policy in various ways. When a client attempts to change the size or
position of a window, the operation may be "redirected" to a specified
client, rather than the operation actually being performed.
Reply
Information requested by a client program is sent back to the client
with a "reply". Both events and replys are multipexed on the same
connection. Most requests do not generate replies.
Request
A command to the server is called a "request". It is a single block of
data sent over a connection.
Resource
Windows, pixmaps, cursors, fonts, graphics contexts, and colormaps are
known as "resources". They all have unique identifiers associated with
them for naming purposes. The lifetime of a resource is bounded by the
lifetime of the connection over which the resource was created.
Root
The "root" of a pixmap or gcontext is the same as the root of whatever
drawable was used when the pixmap or gcontext was created. The "root"
of a window is the root window under which the window was created.
Root window
Each screen has a "root window" covering it. It cannot be reconfigured
or unmapped, but otherwise acts as a full fledged window. A root
window has no parent.
Save set
The "save set" of a client is a list of other client's windows which,
if they are inferiors of one of the client's windows at connection
close, should not be destroyed, and which should be remapped if it is
unmapped. Save sets are typically used by window managers to avoid
lost windows if the manager should terminate abnormally.
Screen
A server may provide several independent "screens", which typically
have physically independent monitors. This would be the expected
configuration when there is only a single keyboard and pointer shared
among the screens.
Server
The "server" provides the basic windowing mechanism. It handles IPC
connections from clients, demultipexes graphics requests onto the
screens, and multiplexes input back to the appropriate clients.
Server grabbing
The server can be "grabbed" by a single client for exclusive use. This
prevents processing of any requests from other client connections until
the grab is complete. This is typically only a transient state for
such things as rubber-banding and pop-up menus, or to execute requests
indivisibly.
Sibling
Children of the same parent window are known as "sibling" windows.
Stacking order
Sibling windows may "stack" on top of each other. Windows above both
obscure and occlude lower windows. This is similar to paper on a desk.
The relationship between sibling windows is known as the "stacking
order".
Stipple
A "stipple pattern" is a bitmap that is used to tile a region to serve
as an additional clip mask for a fill operation with the foreground
color.
Tile
A pixmap can be replicated in two dimensions to "tile" a region. The
pixmap itself is also known as a "tile".
Timestamp
A time value, expressed in milliseconds, typically since the last
server reset. Timestamp values wrap around (after about 49.7 days).
The server, given its current time is represented by timestamp T,
always interprets timestamps from clients by treating half of the
timestamp space as being earlier in time than T, and half of the
timestamp space as being later in time than T. One timestamp value
(named CurrentTime) is never generated by the server; this value is
reserved for use in requests to represent the current server time.
Type
A type is an arbitrary atom used to identify the interpretation of
property data. Types are completely uninterpreted by the server; they
are solely for the benefit of clients.
Unviewable
A window is "unviewable" if it is mapped but some ancestor is unmapped.
Viewable
A window is "viewable" if it and all of its ancestors are mapped. This
does not imply that any portion of the window is actually visible.
Visible
A region of a window is "visible" if someone looking at the screen can
actually "see" it: the window is viewable and the region is not
occluded by any other window.
Window gravity
When windows are resized, subwindows may be repositioned automatically
relative to some position in the window. This attraction of a
subwindow to some part of its parent is known as "window gravity".
Window manager
Manipulation of windows on the screen, and much of the user interface
(policy) is typically provided by a "window manager" client.
XYFormat
The data for a pixmap is said to be in "XYFormat" if it is organized as
a set of bitmaps representing individual bit planes.
ZFormat
The data for a pixmap is said to be in "ZFormat" if it is organized as
a set of pixel values in scanline order.
SECTION 2. PROTOCOL FORMATS
Request Format
Every request contains an 8-bit "major" opcode, and a 16-bit length field
expressed in units of 4 bytes. Every request consists of 4 bytes of header
(containing the major opcode, the length field, and a data byte) followed by
zero or more additional bytes of data; the length field defines the total
length of the request, including the header. The length field in a request
must equal the minimum length required to contain the request; if the
specified length is smaller or larger than the required length, an error is
generated. Unused bytes in a request are not required to be zero. Major
opcodes 128 through 255 are reserved for extensions. Extensions are intended
to contain multiple requests, so extension requests typically have an
additional minor opcode encoded in the "spare" data byte in the request
header, but the placement and interpretation of this minor opcode, and all
other fields in extension requests, are not defined by the core protocol.
Every request is implicitly assigned a sequence number, starting with one,
used in replies, errors, and events.
Reply Format
Every reply contains a 32-bit length field expressed in units of 4 bytes.
Every reply consists of 32 bytes, followed by zero or more additional bytes of
data, as specified in the length field. Unused bytes within a reply are not
guaranteed to be zero. Every reply also contains the least significant 16
bits of the sequence number of the corresponding request.
Error Format
Error reports are 32 bytes long. Every error includes an 8-bit error code.
Error codes 128 through 255 are reserved for extensions. Every error also
includes the major and minor opcodes of the failed request, and the least
significant 16 bits of the sequence number of the request. For the following
errors (see Section 5), the failing resource id is also returned: Colormap,
Cursor, Drawable, Font, GContext, IDChoice, Pixmap, and Window. For Atom
errors, the failing atom is returned. For Value errors, the failing value is
returned. Other core errors return no additional data. Unused bytes within
an error are not guaranteed to be zero.
Event Format
Events are 32 bytes long. Unused bytes within an event are not guaranteed to
be zero. Every event contains an 8-bit type code. The most significant bit
in this code is set if the event was generated from a SendEvent request.
Event codes 64 through 127 are reserved for extensions, although the core
protocol does not define a mechanism for selecting interest in such events.
Every core event (with the exception of KeymapNotify) also contains the least
significant 16 bits of the sequence number of the last request issued by the
client that was (or is currently being) processed by the server.
SECTION 3. SYNTAX
The syntax {...} encloses a set of alternatives.
The syntax [...] encloses a set of structure components.
In general, TYPEs are in upper case and AlternativeValues are capitalized.
Requests in Section 10 are described in the following format:
RequestName
arg1: type1
...
argN: typeN
=>
result1: type1
...
resultM: typeM
Errors: kind1, ..., kindK
Description.
If no => is present in the description, then the request has no reply (it is
asynchronous), although errors may still be reported.
Events in Section 12 are described in the following format:
EventName
value1: type1
...
valueN: typeN
Description.
SECTION 4. COMMON TYPES
LISTofFOO
A type name of the form LISTofFOO means a counted list of elements of type
FOO; the size of the length field may vary (it is not necessarily the same
size as a FOO), in some cases may be implicit, and is not fully specified in
this document.
BITMASK and LISTofVALUE
The types BITMASK and LISTofVALUE are somewhat special. Various requests
contain arguments of the form:
value-mask: BITMASK
value-list: LISTofVALUE
used to allow the client to specify a subset of a heterogeneous collection of
"optional" arguments. The value-mask specifies which arguments are to be
provided; each such argument is assigned a unique bit position. The
representation of the BITMASK will typically contain more bits than there are
defined arguments; unused bits in the value-mask must be zero (or the server
generates a Value error). The value-list contains one value for each one bit
in the mask, from least to most significant bit in the mask. Each value is
represented with 4 bytes, but the actual value occupies only the least
significant bytes as required; the values of the unused bytes do not matter.
Or Types
A type of the form "T1 or ... or Tn" means the union of the indicated types; a
single-element type is given as the element without enclosing braces.
DEVICE: 32-bit id (<class,model,manufacturer,unit> 8 bits each)
WINDOW: 32-bit id
PIXMAP: 32-bit id
CURSOR: 32-bit id
FONT: 32-bit id
GCONTEXT: 32-bit id
COLORMAP: 32-bit id
DRAWABLE: WINDOW or PIXMAP
ATOM: 32-bit id (top 3 bits guaranteed to be zero)
VISUALID: 32-bit id (top 3 bits guaranteed to be zero)
VALUE: 32-bit quantity (used only in LISTofVALUE)
INT8: 8-bit signed integer
INT16: 16-bit signed integer
INT32: 32-bit signed integer
CARD8: 8-bit unsigned integer
CARD16: 16-bit unsigned integer
CARD32: 32-bit unsigned integer
TIMESTAMP: CARD32
BITGRAVITY: {Forget, Static,
NorthWest, North, NorthEast,
West, Center, East,
SouthWest, South, SouthEast}
WINGRAVITY: {Unmap, Static,
NorthWest, North, NorthEast,
West, Center, East,
SouthWest, South, SouthEast}
BOOL: {True, False}
EVENT: {KeyPress, KeyRelease,
OwnerGrabButton,
ButtonPress, ButtonRelease, EnterWindow, LeaveWindow,
PointerMotion, PointerMotionHint,
Button1Motion, Button2Motion, Button3Motion,
Button4Motion, Button5Motion, ButtonMotion
Exposure, VisibilityChange,
StructureNotify, ResizeRedirect,
SubstructureNotify, SubstructureRedirect,
FocusChange,
PropertyChange, ColormapChange,
KeymapState}
POINTEREVENT: {ButtonPress, ButtonRelease, EnterWindow, LeaveWindow,
PointerMotion, PointerMotionHint,
Button1Motion, Button2Motion, Button3Motion,
Button4Motion, Button5Motion, ButtonMotion
KeymapState}
DEVICEEVENT: {KeyPress, KeyRelease,
ButtonPress, ButtonRelease,
PointerMotion,
Button1Motion, Button2Motion, Button3Motion,
Button4Motion, Button5Motion, ButtonMotion}
KEYCODE: CARD8
BUTTON: CARD8
KEYMASK: {Shift, CapsLock, Control, Mod1, Mod2, Mod3, Mod4, Mod5}
BUTMASK: {Button1, Button2, Button3, Button4, Button5}
KEYBUTMASK: KEYMASK or BUTMASK
STRING8: LISTofCARD8
STRING16: LISTofCHAR2B
CHAR2B: [byte1, byte2: CARD8]
POINT: [x, y: INT16]
RECTANGLE: [x, y: INT16,
width, height: CARD16]
ARC: [x, y: INT16,
width, height: CARD16,
angle1, angle2: INT16]
HOST: [family: {Internet, NS, ECMA, Datakit, DECnet}
address: LISTofCARD8]
The [x,y] coordinates of a RECTANGLE specify the upper left corner.
The primary interpretation of "large" characters in a STRING16 is that they
are composed of two bytes used to index a 2-D matrix; hence the use of CHAR2B
rather than CARD16. This corresponds to the JIS/ISO method of indexing
two-byte characters. It is expected that most "large" fonts will be defined
with two-byte matrix indexing. For large fonts constructed with linear
indexing, a CHAR2B can be interpreted as a 16-bit number by treating byte1 as
the most significant byte; this means that clients should always transmit such
16-bit character values most significant byte first, as the server will never
byte-swap CHAR2B quantities.
The length, format, and interpretation of a HOST address are specific to the
family.
SECTION 5. ERRORS
In general, when a request terminates with an error, the request has no side
effects (i.e., there is no partial execution). The only requests for which
this is not true are ChangeWindowAttributes, ChangeGC, PolyText8, PolyText16,
FreeColors, StoreColors, and ChangeKeyboardControl.
The following error codes can be returned by the various requests:
Access
An attempt to grab a key/button combination already grabbed by another
client.
An attempt to free a colormap entry not allocated by the client.
An attempt to store into a read-only or an unallocated colormap entry.
An attempt to modify the access control list from other than the local
(or otherwise authorized) host.
An attempt to select an event type, that at most one client can
select at a time, when another client has already selected it.
Alloc
The server failed to allocate the requested resource.
Note that this only covers allocation errors at a very coarse level,
and is not intended to (nor can it in practice hope to) cover all cases
of a server running out of allocation space in the middle of service.
The semantics when a server runs out of allocation space are left
unspecified.
Atom
A value for an ATOM argument does not name a defined ATOM.
Colormap
A value for a COLORMAP argument does not name a defined COLORMAP.
Cursor
A value for a CURSOR argument does not name a defined CURSOR.
Drawable
A value for a DRAWABLE argument does not name a defined WINDOW or
PIXMAP.
Font
A value for a FONT or <FONT or GCONTEXT> argument does not name a
defined FONT.
GContext
A value for a GCONTEXT argument does not name a defined GCONTEXT.
IDChoice
The value chosen for a resource identifier is either not included
in the range assigned to the client, or is already in use.
Implementation
The server does not implement some aspect of the request. A server
which generates this error for a core request is deficient. As such,
this error is not listed for any of the requests, but clients should be
prepared to receive such errors, and handle or discard them.
Length
The length of a request is shorter or longer than that required
to minimally contain the arguments.
Match
An InputOnly window is used as a DRAWABLE.
Some argument (or pair of arguments) has the correct type and range,
but fails to "match" in some other way required by the request.
Name
A font or color of the specified name does not exist.
Pixmap
A value for a PIXMAP argument does not name a defined PIXMAP.
Property
The requested property does not exist for the specified window.
Request
The major or minor opcode does not specify a valid request.
Value
Some numeric value falls outside the range of values accepted by the
request. Unless a specific range is specified for an argument, the
full range defined by the argument's type is accepted. Any argument
defined as a set of alternatives can generate this error.
Window
A value for a WINDOW argument does not name a defined WINDOW.
Note: the Atom, Colormap, Cursor, Drawable, Font, GContext, Pixmap, and Window
errors are also used when the argument type is extended by union with a set of
fixed alternatives, e.g., <Window or PointerRoot or None>.
∂01-Jun-87 0529 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 4 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:28:53 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:27-EDT
Date: Mon, 1 Jun 87 08:28 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 4 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082815.9.RWS@KILLINGTON.LCS.MIT.EDU>
QueryFont
font: FONT or GCONTEXT
=>
font-info: FONTINFO
char-infos: LISTofCHARINFO
where
FONTINFO: [draw-direction: {LeftToRight, RightToLeft}
min-char-or-byte2, max-char-or-byte2: CARD16
min-byte1, max-byte1: CARD8
all-chars-exist: BOOL
default-char: CARD16
min-bounds: CHARINFO
max-bounds: CHARINFO
font-ascent: INT16
font-descent: INT16
properties: LISTofFONTPROP]
FONTPROP: [name: ATOM
value: INT32 or CARD32]
CHARINFO: [left-side-bearing: INT16
right-side-bearing: INT16
character-width: INT16
ascent: INT16
descent: INT16
attributes: CARD16]
Errors: Font
Returns logical information about a font.
The draw-direction is essentially just a hint, indicating whether most
char-infos have a positive (LeftToRight) or a negative (RightToLeft)
character-width metric. The core protocol defines no support for
vertical text.
If min-byte1 and max-byte1 are both zero, then min-char-or-byte2
specifies the linear character index corresponding to the first elementb
of char-infos, and max-char-or-byte2 specifies the linear character
index of the last element. If either min-byte1 or max-byte1 are
non-zero, then both min-char-or-byte2 and max-char-or-byte2 will be
less than 256, and the two-byte character index values corresponding to
char-infos element N (counting from 0) are
byte1 = N/D + min-byte1
byte2 = N\D + min-char-or-byte2
where
D = max-char-or-byte2 - min-char-or-byte2 + 1
/ = integer division
\ = integer modulus
If char-infos has length zero, then min-bounds and max-bounds will be
identical, and the effective char-infos is one filled with this
char-info, of length
L = D * (max-byte1 - min-byte1 + 1)
That is, all glyphs in the specified linear or matrix range have the
same information, as given by min-bounds (and max-bounds). If
all-chars-exist is True, then all characters in char-infos have
non-zero bounding boxes.
The default-char specifies the character that will be used when an
undefined or non-existent character is used. Note that default-char is
a CARD16 (not CHAR2B); for a font using two-byte matrix format, the
default-char has byte1 in the most significant byte, and byte2 in the
least significant byte. If the default-char itself specifies an
undefined or non-existent character, then no printing is performed for
an undefined or non-existent character.
The min-bounds and max-bounds contain the minimum and maximum values of
each individual CHARINFO component over all char-infos (ignoring
non-existent characters). The bounding box of the font, i.e., the
smallest rectangle enclosing the shape obtained by superimposing all
characters at the same origin [x,y], has its upper left coordinate at
[x + min-bounds.left-side-bearing, y - max-bounds.ascent]
with a width of
max-bounds.right-side-bearing - min-bounds.left-side-bearing
and a height of
max-bounds.ascent + max-bounds.descent
The font-ascent is the logical extent of the font above the baseline,
for determining line spacing. Specific characters may extend beyond
this. The font-descent is the logical extent of the font at or below
the baseline, for determining line spacing. Specific characters may
extend beyond this. If the baseline is at Y-coordinate y, then the
logical extent of the font is inclusive between the Y-coordinate values
(y - font-ascent) and (y + font-descent - 1).
A font is not guaranteed to have any properties. Whether a property
value is signed or unsigned must be derived from a priori knowledge of
the property. When possible, fonts should have at least the following
properties (note that the trailing colon is not part of the name, and
that upper/lower case matters).
MinSpace: CARD32
The minimum interword spacing, in pixels.
NormSpace: CARD32
The normal interword spacing, in pixels.
MaxSpace: CARD32
The maximum interword spacing, in pixels.
EndSpace: CARD32
The additional spacing at the end of sentences, in pixels.
SuperscriptX: INT32
SuperscriptY: INT32
Offsets from the character origin where superscripts should begin,
in pixels. If the origin is at [x,y], then superscripts should
begin at [x + SuperscriptX, y - SuperscriptY].
SubscriptX: INT32
SubscriptY: INT32
Offsets from the character origin where subscripts should begin, in
pixels. If the origin is at [x,y], then subscripts should begin at
[x + SubscriptX, y + SubscriptY].
UnderlinePosition: INT32
Y offset from the baseline to the top of an underline, in pixels.
If the baseline is Y-coordinate y, then the top of the underline is
at (y + UnderlinePosition).
UnderlineThickness: CARD32
Thickness of the underline, in pixels.
StrikeoutAscent: INT32
StrikeoutDescent: INT32
Vertical extents for boxing or voiding characters, in pixels. If
the baseline is at Y-coordinate y, then the top of the strikeout
box is at (y - StrikeoutAscent), and the height of the box is
(StrikeoutAscent + StrikeoutDescent).
ItalicAngle: INT32
The angle of characters in the font, in degrees scaled by 64,
relative to the three-oclock position from the character origin,
with positive indicating counterclockwise motion (as in Arc
requests).
XHeight: INT32
"1 ex" as in TeX, but expressed in units of pixels. Often the
height of lowercase x.
QuadWidth: INT32
"1 em" as in TeX, but expressed in units of pixels. Often the
width of the digits 0-9.
Weight: CARD32
The weight or boldness of the font, expressed as a value between 0
and 1000.
PointSize: CARD32
The point size, expressed in 1/10ths, of this font at the ideal
resolution. There are 72.27 points to the inch.
Resolution: CARD32
The number of pixels per point, expressed in 1/100ths, at which
this font was created.
For a character origin at [x,y], the bounding box of a character, i.e.,
the smallest rectangle enclosing the character's shape, described in
terms of CHARINFO components, is a rectangle with its upper left corner
at
[x + left-side-bearing, y - ascent]
with a width of
right-side-bearing - left-side-bearing
and a height of
ascent + descent
and the origin for the next character is defined to be
[x + character-width, y]
Note that the baseline is logically viewed as being just below
non-descending characters (when descent is zero, only pixels with
Y-coordinates less than y are drawn), and that the origin is logically
viewed as being coincident with the left edge of a non-kerned character
(when left-side-bearing is zero, no pixels with X-coordinate less than
x are drawn).
Note that CHARINFO metric values can be negative.
A non-existent character is represented with all CHARINFO components
zero.
The interpretation of the per-character attributes field is undefined
by the core protocol.
QueryTextExtents
font: FONT or GCONTEXT
items: STRING16
=>
draw-direction: {LeftToRight, RightToLeft}
font-ascent: INT16
font-descent: INT16
overall-ascent: INT16
overall-descent: INT16
overall-width: INT32
overall-left: INT32
overall-right: INT32
Errors: Font
Returns the logical extents of the specified string of characters in
the specified font. Draw-direction, font-ascent, and font-descent are
as described in QueryFont. Overall-ascent is the maximum of the ascent
metrics of all characters in the string, and overall-descent is the
maximum of the descent metrics. Overall-width is the sum of the
character-width metrics of all characters in the string. For each
character in the string, let W be the sum of the character-width
metrics of all characters preceding it in the string, let L be the
left-side-bearing metric of the character plus W, and let R be the
right-side-bearing metric of the character plus W. Overall-left is the
minimum L of all characters in the string, and overall-right is the
maximum R.
For fonts defined with linear indexing rather than two-byte matrix
indexing, the server will interpret each CHAR2B as a 16-bit number that
has been transmitted most significant byte first (i.e., byte1 of the
CHAR2B is taken as the most significant byte).
If the font has no defined default-char, then undefined characters in
the string are taken to have all zero metrics.
ListFonts
pattern: STRING8
max-names: CARD16
=>
names: LISTofSTRING8
Returns a list of length at most max-names, of names of fonts matching
the pattern. The pattern should use the ASCII encoding, and
upper/lower case does not matter. In the pattern, the '?' character
(octal value 77) will match any single character, and the character '*'
(octal value 52) will match any number of characters. The returned
names are in lower case.
ListFontsWithInfo
pattern: STRING8
max-names: CARD16
=>
fonts: LISTofFONTDATA
where
FONTDATA: [name: STRING8
info: FONTINFO]
FONTINFO: <same type definition as in QueryFont>
Like ListFonts, but also returns information about each font. The
information returned for each font is identical to what QueryFont would
return (except that the per-character metrics are not returned).
SetFontPath
path: LISTofSTRING8
Errors: Value
Defines the search path for font lookup. There is only one search path
per server, not one per client. The interpretation of the strings is
operating system dependent, but they are intended to specify
directories to be searched in the order listed.
Setting the path to the empty list restores the default path defined
for the server.
As a side-effect of executing this request, the server is guaranteed to
flush all cached information about fonts for which there currently are
no explicit resource ids allocated.
The meaning of an error from this request is system specific.
GetFontPath
=>
path: LISTofSTRING8
Returns the current search path for fonts.
CreatePixmap
pid: PIXMAP
drawable: DRAWABLE
depth: CARD8
width, height: CARD16
Errors: IDChoice, Drawable, Value, Alloc
Creates a pixmap, and assigns the identifier pid to it. Width and
height must be non-zero. Depth must be one of the depths supported by
root of the specified drawable. The initial contents of the pixmap are
undefined.
It is legal to pass an InputOnly window as a drawable to this request.
FreePixmap
pixmap: PIXMAP
Errors: Pixmap
Deletes the association between the resource id and the pixmap. The
pixmap storage will be freed when no other resource references it.
CreateGC
cid: GCONTEXT
drawable: DRAWABLE
value-mask: BITMASK
value-list: LISTofVALUE
Errors: IDChoice, Drawable, Pixmap, Font, Match, Value, Alloc
Creates a graphics context, and assigns the identifier cid to it. The
gcontext can be used with any destination drawable having the same root
and depth as the specified drawable.
The value-mask and value-list specify which components are to be
explicitly initialized. The context components are:
alu-function: {Clear, And, AndReverse, Copy, AndInverted, Noop,
Xor, Or, Nor, Equiv, Invert, OrReverse,
CopyInverted, OrInverted, Nand, Set}
plane-mask: CARD32
foreground: CARD32
background: CARD32
line-width: CARD16
line-style: {Solid, OnOffDash, DoubleDash}
cap-style: {NotLast, Butt, Round, Projecting}
join-style: {Miter, Round, Bevel}
fill-style: {Solid, Tiled, OpaqueStippled, Stippled}
fill-rule: {EvenOdd, Winding}
arc-mode: {Chord, PieSlice}
tile: PIXMAP
stipple: PIXMAP
tile-stipple-x-origin: INT16
tile-stipple-y-origin: INT16
font: FONT
subwindow-mode: {ClipByChildren, IncludeInferiors}
graphics-exposures: BOOL
clip-x-origin: INT16
clip-y-origin: INT16
clip-mask: PIXMAP or None
dash-offset: CARD16
dash-list: CARD8
In graphics operations, given a source and destination pixel, the
result is computed bitwise on corresponding bits of the pixels. That
is, a boolean operation is performed in each bit plane. The plane-mask
restricts the operation to a subset of planes. That is, the result is
((src FUNC dst) AND plane-mask) OR (dst AND (NOT plane-mask))
Range checking is not performed on the values for foreground,
background, or plane-mask; they are simply truncated to the appropriate
number of bits.
The meanings of the alu-functions are:
Clear 0
And src AND dst
AndReverse src AND (NOT dst)
Copy src
AndInverted (NOT src) AND dst
NoOp dst
Xor src XOR dst
Or src OR dst
Nor (NOT src) AND (NOT dst)
Equiv (NOT src) XOR dst
Invert NOT dst
OrReverse src OR (NOT dst)
CopyInverted NOT src
OrInverted (NOT src) OR dst
NAnd (NOT src) OR (NOT dst)
Set 1
Line-width is measured in pixels and can be greater than or equal to
one (a "wide" line) or the special value zero (a "thin" line).
Wide lines are drawn centered on the path described by the graphics
request. Unless otherwise specified by the join or cap style, the
bounding box of a wide line with endpoints [x1, y1], [x2, y2], and
width w is a rectangle with vertices at the following real coordinates:
[x1-(w*sn/2), y1+(w*cs/2)], [x1+(w*sn/2), y1-(w*cs/2)],
[x2-(w*sn/2), y2+(w*cs/2)], [x2+(w*sn/2), y2-(w*cs/2)]
where sn is the sine of the angle of the line and cs is the cosine of
the angle of the line. A pixel is part of the line (and hence drawn)
if the center of the pixel is fully inside the bounding box (which is
viewed as having infinitely thin edges). If the center of the pixel is
exactly on the bounding box, it is part of the line if and only if the
interior is immediately to its right (x increasing direction). Pixels
with centers on a horizontal edge are a special case and are part of
the line if and only if the interior is immediately below (y increasing
direction). Note that this description is a mathematical model
describing the pixels that are drawn for a wide line and does not imply
that trigonometry is required to implement such a model. Real or fixed
point arithmetic is recommended for computing the corners of the line
endpoints for lines greater than one pixel in width.
Thin lines (zero line-width) are "one pixel wide" lines drawn using an
unspecified, device dependent algorithm (for example, Bresenham).
There are only two constraints on this algorithm. First, if a line is
drawn unclipped from [x1,y1] to [x2,y2] and another line is drawn
unclipped from [x1+dx,y1+dy] to [x2+dx,y2+dy], then a point [x,y] is
touched by drawing the first line if and only if the point [x+dx,y+dy]
is touched by drawing the second line. Second, the effective set of
points comprising a line cannot be affected by clipping; that is, a
point is touched in a clipped line if and only if the point lies inside
the clipping region and the point would be touched by the line when
drawn unclipped.
Note that a wide line drawn from [x1,y1] to [x2,y2] always draws the
same pixels as a wide line drawn from [x2,y2] to [x1,y1], not counting
cap and join styles, but this property is not guaranteed for thin
lines. Also note that "jags" in adjacent wide lines will always line
up properly, but this property is not guaranteed for thin lines. A
line-width of zero differs from a line-width of one in which pixels are
drawn. In general, drawing a thin line will be faster than drawing a
wide line of width one, but thin lines may not mix well aesthetically
with wide lines because of the different drawing algorithms. If it is
desirable to obtain precise and uniform results across all displays, a
client should always use a line-width of one, rather than a line-width
of zero.
The line-style defines which segments of a line are drawn:
Solid: the full path of the line is drawn
DoubleDash: the full path of the line is drawn, but the segments
defined by the even dashes are filled differently than
the segments defined by the odd dashes (see fill-style)
OnOffDash: only the segments defined by the even dashes are drawn,
and cap-style applies to each individual segment (except
NotLast is treated as Butt for internal caps)
The cap-style defines how the endpoints of a path are drawn:
NotLast: equivalent to Butt, except that for a line-width
of zero or one the final endpoint is not drawn
Butt: square at the endpoint, with no projection beyond
Round: a circular arc with diameter equal to the line-width,
centered on the endpoint; equivalent to Butt for line-width
zero or one
Projecting: square at the end, but the path continues beyond the
endpoint for a distance equal to half the line-width;
equivalent to Butt for line-width zero or one
The join-style defines how corners are drawn for wide lines:
Miter: the outer edges of the two lines extend to meet at an
angle
Round: a circular arc with diameter equal to the line-width,
centered on the joinpoint
Bevel: Butt endpoint styles, and then the triangular "notch" filled
The tile/stipple and clip origins are interpreted relative to the
origin of whatever destination drawable is specified in a graphics
request.
The tile pixmap must have the same root and depth as the gcontext (else
a Match error). The stipple pixmap must have depth one, and must have
the same root as the gcontext (else a Match error). For stipple
operations, the stipple pattern is tiled in a single plane, and acts as
an additional clip mask to be ANDed with the clip-mask. Any size
pixmap can be used for tiling or stippling, although some sizes may be
faster to use than others.
The fill-style defines the contents of the source for line, text, and
fill requests. For all text and fill requests (PolyText8, PolyText16,
PolyFillRectangle, FillPoly, PolyFillArc), for line requests (PolyLine,
PolySegment, PolyRectangle, PolyArc) with line-style Solid, and for the
even dashes for line requests with line-style OnOffDash or DoubleDash:
Solid: foreground
Tiled: tile
OpaqueStippled: a tile with the same width and height as stipple,
but with background everywhere stipple has a zero
and with foreground everywhere stipple has a one
Stippled: foreground masked by stipple
For the odd dashes for line requests with line-style DoubleDash:
Solid: background
Tiled: same as for even dashes
OpaqueStippled: same as for even dashes
Stippled: background masked by stipple
The dash-list value allowed here is actually a simplified form of the
more general patterns that can be set with SetDashes. Specifying a
value of N here is equivalent to specifying the two element list [N, N]
in SetDashes. The value must be non-zero. The meaning of dash-offset
and dash-list are explained in the SetDashes request.
The clip-mask restricts writes to the destination drawable; only pixels
where the clip-mask has a one bit are drawn. It affects all graphics
requests. The clip-mask does not clip sources. The clip-mask origin
is interpreted relative to the origin of whatever destination drawable
is specified in a graphics request. If a pixmap is specified as the
clip-mask, it must have depth one and have the same root as the
gcontext (else a Match error). The clip-mask can also be set with the
SetClipRectangles request.
For ClipByChildren, both source and destination windows are
additionally clipped by all viewable InputOutput children. For
IncludeInferiors, neither source nor destination window is clipped by
inferiors; this will result in drawing through subwindow boundaries.
The use of IncludeInferiors on a window of one depth with mapped
inferiors of differing depth is not illegal, but the semantics is
undefined by the core protocol.
The fill-rule defines what pixels are inside (i.e., are drawn) for
paths given in FillPoly requests. EvenOdd means a point is inside if
an infinite ray with the point as origin crosses the path an odd number
of times. For Winding, a point is inside if an infinite ray with the
point as origin crosses an unequal number of clockwise and
counterclockwise directed path segments. For both rules, a "point" is
infinitely small, and the path is an infinitely thin line. A pixel is
inside if the center point of the pixel is inside and the center point
is not on the boundary. If the center point is on the boundary, the
pixel is inside if and only if the polygon interior is immediately to
its right (x increasing direction). Pixels with centers along a
horizontal edge are a special case and are inside if and only if the
polygon interior is immediately below (y increasing direction).
The arc-mode controls filling in the PolyFillArc request.
The graphics-exposures flag controls GraphicsExposure event generation
for CopyArea and CopyPlane requests (and any similar requests defined
by extensions).
The default component values are:
function: Copy
plane-mask: all ones
foreground: 0
background: 1
line-width: 0
line-style: Solid
cap-style: Butt
join-style: Miter
fill-style: Solid
full-rule: EvenOdd
arc-mode: PieSlice
tile: pixmap of unspecified size filled with foreground pixel
(i.e., client specified pixel if any, else 0)
stipple: pixmap of unspecified size filled with ones
tile-stipple-x-origin: 0
tile-stipple-y-origin: 0
font: <implementation dependent>
subwindow-mode: ClipByChildren
graphics-exposures: True
clip-x-origin: 0
clip-y-origin: 0
clip-mask: None
dash-offset: 0
dash-list: 4 (i.e., the list [4, 4])
Storing a pixmap in a gcontext might or might not result in a copy
being made. If the pixmap is later used as the destination for a
graphics request, the change might or might not be reflected in the
gcontext. If the pixmap is used simultaneously in a graphics request
as both a destination and as a tile or stipple, the results are not
defined.
It is quite likely that some amount of gcontext information will be
cached in display hardware, and that such hardware can only cache a
small number of gcontexts. Given the number and complexity of
components, clients should view switching between gcontexts with nearly
identical state as significantly more expensive than making minor
changes to a single gcontext.
ChangeGC
gc: GCONTEXT
value-mask: BITMASK
value-list: LISTofVALUE
Errors: GContext, Pixmap, Font, Match, Value, Alloc
Changes components in gc. The value-mask and value-list specify which
components are to be changed. The values and restrictions are the same
as for CreateGC.
Changing the clip-mask also overrides any previous SetClipRectangles
request on the context. Changing the dash-offset or dash-list
overrides any previous SetDashes request on the context.
The order in which components are verified and altered is server
dependent. If an error is generated, a subset of the components may
have been altered.
CopyGC
src-gc, dst-gc: GCONTEXT
value-mask: BITMASK
Errors: GContext, Value, Match, Alloc
Copies components from src-gc to dst-gc. The value-mask specifies
which components to copy, as for CreateGC. The two gcontexts must have
the same root and the same depth (else a Match error).
SetDashes
gc: GCONTEXT
dash-offset: CARD16
dash-list: LISTofCARD8
Errors: GContext, Value, Alloc
Sets the dash-offset and dash-list in gc for dashed line styles. The
initial and alternating elements of the dash-list are the "even"
dashes, the others are the "odd" dashes. All of the elements must be
non-zero. The dash-offset defines the phase of the pattern, specifying
how many pixels into the dash-list the pattern should actually begin in
any single graphics request. Dashing is continuous through path
segments combined with a join-style, but is reset to the dash-offset
each time a cap-style is applied.
SetClipRectangles
gc: GCONTEXT
clip-x-origin, clip-y-origin: INT16
rectangles: LISTofRECTANGLE
ordering: {UnSorted, YSorted, YXSorted, YXBanded}
Errors: GContext, Value, Alloc, Match
Changes clip-mask in gc to the specified list of rectangles and sets
the clip origin. Output will be clipped to remain contained within the
rectangles. The clip origin is interpreted relative to the origin of
whatever destination drawable is specified in a graphics request. The
rectangle coordinates are interpreted relative to the clip origin. The
rectangles should be non-intersecting, or graphics results will be
undefined.
If known by the client, ordering relations on the rectangles can be
specified with the ordering argument; this may provide faster operation
by the server. If an incorrect ordering is specified, the server may
generate a Match error, but is not required to do so; if no error is
generated, the graphics results are undefined. UnSorted means the
rectangles are in arbitrary order. YSorted means that the rectangles
are non-decreasing in their Y origin. YXSorted additionally constrains
YSorted order in that all rectangles with an equal Y origin are
non-decreasing in their X origin. YXBanded additionally constrains
YXSorted by requiring that for every possible Y scanline, all
rectangles that include that scanline have identical Y origins and Y
extents.
FreeGC
gc: GCONTEXT
Errors: GContext
Deletes the association between the resource id and the gcontext, and
destroys the gcontext.
ClearToBackground
window: WINDOW
x, y: INT16
width, height: CARD16
exposures: BOOL
Errors: Window, Value, Match
The x and y coordinates are relative to the window's origin, and
specify the upper left corner of the rectangle. If width is zero, it
is replaced with the current width of the window minus x. If height is
zero, it is replaced with the current height of the window minus y. If
the window has a defined background tile, the rectangle is tiled with a
plane-mask of all ones and alu-function of Copy. If the window has
background None, the contents of the window are not changed. In either
case, if exposures is True, then one or more exposure events are
generated for regions of the rectangle that are either visible or are
being retained in a backing store.
It is a Match error to use an InputOnly window in this request.
CopyArea
src-drawable, dst-drawable: DRAWABLE
gc: GCONTEXT
src-x, src-y: INT16
width, height: CARD16
dst-x, dst-y: INT16
Errors: Drawable, GContext, Match
Combines the specified rectangle of src-drawable with the specified
rectangle of dst-drawable. The src-x and src-y coordinates are
relative to src-drawable's origin, dst-x and dst-y are relative to
dst-drawable's origin, each pair specifying the upper left corner of
the rectangle. Src-drawable must have the same root and the same depth
as dst-drawable (else a Match error).
If regions of the source rectangle are obscured and have not been
retained by the server, or if regions outside the boundaries of the
source drawable are specified, then the following occurs. If the
dst-drawable is a window with a background of other than None, the
corresponding regions of the destination are tiled (with plane-mask of
all ones and alu-function Copy) with that background. Regardless, if
graphics-exposures in gc is True, GraphicsExposure events for the
corresponding destination regions are generated.
If graphics-exposures is True but no regions are exposed, then a
NoExposure event is generated.
GC components: alu-function, plane-mask, subwindow-mode,
graphics-exposures, clip-x-origin, clip-y-origin, clip-mask
CopyPlane
src-drawable, dst-drawable: DRAWABLE
gc: GCONTEXT
src-x, src-y: INT16
width, height: CARD16
dst-x, dst-y: INT16
bit-plane: CARD32
Errors: Drawable, GContext, Value, Match
Src-drawable must have the same root as dst-drawable (else a Match
error), but need not have the same depth. Bit-plane must have exactly
one bit set. Effectively, that plane of the src-drawable and the
foreground/background pixels in gc are combined to form a pixmap of the
same depth as dst-drawable, and the equivalent of a CopyArea is
performed, with all the same exposure semantics.
GC components: alu-function, plane-mask, foreground, background,
subwindow-mode, graphics-exposures, clip-x-origin, clip-y-origin,
clip-mask
PolyPoint
drawable: DRAWABLE
gc: GCONTEXT
coordinate-mode: {Origin, Previous}
points: LISTofPOINT
Errors: Drawable, GContext, Value, Match
Combines the foreground pixel in gc with the pixel at each point in the
drawable. The points are drawn in the order listed.
The first point is always relative to the drawable's origin; the rest
are relative either to that origin or the previous point, depending on
the coordinate-mode.
GC components: alu-function, plane-mask, foreground, subwindow-mode,
clip-x-origin, clip-y-origin, clip-mask
PolyLine
drawable: DRAWABLE
gc: GCONTEXT
coordinate-mode: {Origin, Previous}
points: LISTofPOINT
Errors: Drawable, GContext, Value, Match
Draws lines between each pair of points (point[i], point[i+1]). The
lines are drawn in the order listed. The lines join correctly at all
intermediate points, and if the first and last points coincide, the
first and last lines also join correctly.
For any given line, no pixel is drawn more than once. If thin (zero
line-width) lines intersect, the intersecting pixels are drawn multiple
times. If wide lines intersect, the intersecting pixels are drawn only
once, as though the entire PolyLine were a single filled shape.
The first point is always relative to the drawable's origin; the rest
are relative either to that origin or the previous point, depending on
the coordinate-mode.
GC components: alu-function, plane-mask, line-width, line-style,
cap-style, join-style, fill-style, subwindow-mode, clip-x-origin,
clip-y-origin, clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dash-list
PolySegment
drawable: DRAWABLE
gc: GCONTEXT
segments: LISTofSEGMENT
where SEGMENT: [x1, y1, x2, y2: INT16]
Errors: Drawable, GContext, Match
For each segment, draws a line between [x1, y1] and [x2, y2]. The
lines are drawn in the order listed. No joining is performed at
coincident end points. For any given line, no pixel is drawn more than
once. If lines intersect, the intersecting pixels are drawn multiple
times.
GC components: alu-function, plane-mask, line-width, line-style,
cap-style, fill-style, subwindow-mode, clip-x-origin, clip-y-origin,
clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dash-list
PolyRectangle
drawable: DRAWABLE
gc: GCONTEXT
rectangles: LISTofRECTANGLE
Errors: Drawable, GContext, Match
Draws the outlines of the specified rectangles, as if a five-point
PolyLine were specified for each rectangle. The x and y coordinates of
each rectangle are relative to the drawable's origin, and define the
upper left corner of the rectangle.
The rectangles are drawn in the order listed. For any given rectangle,
no pixel is drawn more than once. If rectangles intersect, the
intersecting pixels are drawn multiple times.
GC components: alu-function, plane-mask, line-width, line-style,
join-style, fill-style, subwindow-mode, clip-x-origin, clip-y-origin,
clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dash-list
∂01-Jun-87 0528 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 2 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:27:59 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:26-EDT
Date: Mon, 1 Jun 87 08:27 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 2 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082720.7.RWS@KILLINGTON.LCS.MIT.EDU>
SECTION 6. KEYBOARDS
Keycodes are always in the inclusive range [8,255].
For keyboards with both left-side and right-side modifier keys (e.g., Shift
and Control), the mask bits in the protocol always define the OR of the keys.
If electronically distinguishable, they can have separate up/down events
generated, and clients that want to distinguish can track the individual
states manually.
<As part of the core we need to define a universal association between keycaps
and keycodes. A keycap is the graphical information imprinted on a keyboard
key, e.g., "$ 4", "T", "+ =".>
SECTION 7. POINTERS
Buttons are always numbered starting with one.
SECTION 8. PREDEFINED ATOMS
Predefined atoms are not strictly necessary, and may not be useful in all
environments, but will eliminate many InternAtom requests in most
applications. The core protocol imposes no semantics on these names, except
as they are used in FONTPROP structures (see QueryFont). Note that
upper/lower case matters.
BITMAP ICON_SIZE RGB_GREEN_MAP
COMMAND ITALIC_ANGLE RGB_RED_MAP
COPYRIGHT MAX_SPACE SECONDARY
CUT_BUFFER0 MIN_SPACE SIZE_HINTS
CUT_BUFFER1 NAME STRIKEOUT_ASCENT
CUT_BUFFER2 NORMAL_HINTS STRIKEOUT_DESCENT
CUT_BUFFER3 NORM_SPACE STRING
CUT_BUFFER4 PIXMAP SUBSCRIPT_X
CUT_BUFFER5 POINT_SIZE SUBSCRIPT_Y
CUT_BUFFER6 PRIMARY SUPERSCRIPT_X
CUT_BUFFER7 QUAD_WIDTH SUPERSCRIPT_Y
DEFAULT_CHAR RECTANGLE UNDERLINE_POSITION
END_SPACE RESIZE_HINT UNDERLINE_THICKNESS
FACE_NAME RESOLUTION WEIGHT
FAMILY_NAME RGB_BEST_MAP WINDOW
FONT_ASCENT RGB_BLUE_MAP WM_HINTS
FONT_DESCENT RGB_COLOR_MAP X_HEIGHT
ICON RGB_DEFAULT_MAP ZOOM_HINTS
ICON_NAME
SECTION 9. CONNECTION SETUP
For remote clients, the X protocol can be built on top of any reliable byte
stream. For TCP connections, displays on a given host a numbered starting
from 0, and the server for display N listens and accepts connections on port
6000+N.
The client must send an initial byte of data to identify the byte order to be
employed. The value of the byte must be octal 102 or 154. The value 102
(ASCII uppercase B) means values are transmitted most significant byte first,
and value 154 (ASCII lowercase l) means values are transmitted least
significant byte first. Except where explicitly noted in the protocol, all
16-bit and 32-bit quantities sent by the client must be transmitted with this
byte order, and all 16-bit and 32-bit quantities returned by the server will
be transmitted with this byte order.
Following the byte-order byte, the following information is sent by the client
at connection setup:
protocol-major-version: CARD16
protocol-minor-version: CARD16
authorization-protocol-name: STRING8
authorization-protocol-data: STRING8
The version numbers indicate what version of the protocol the client
expects the server to implement. See below for an explanation.
The authorization name indicates what authorization protocol the client
expects the server to use, and the data is specific to that protocol.
Specification of valid authorization mechanisms is not part of the core
X protocol. It is hoped that eventually one authorization protocol
will be agreed upon. In the mean time, a server that implements a
different protocol than the client expects, or a server that only
implements the host-based mechanism, will simply ignore this
information.
Received by the client at connection setup:
success: BOOL
protocol-major-version: CARD16
protocol-minor-version: CARD16
length: CARD16
Length is the amount of additional data to follow, in units of 4 bytes.
The version numbers are an escape hatch in case future revisions of the
protocol are necessary. In general, the major version would increment
for incompatible changes, and the minor version would increment for
small upward compatible changes. Barring changes, the major version
will be eleven, and the minor version will be zero. The protocol
version numbers returned indicate the protocol the server actually
supports. This might not equal the version sent by the client. The
server can (but need not) refuse connections from clients that offer a
different version than the server supports. A server can (but need
not) support more than one version simultaneously.
Additional data received if authorization fails:
reason: STRING8
Additional data received if authorization is accepted:
vendor: STRING8
release-number: CARD32
resource-id-base, resource-id-mask: CARD32
image-byte-order: {LSBFirst, MSBFirst}
bitmap-format-scanline-unit: {8, 16, 32}
bitmap-format-scanline-pad: {8, 16, 32}
bitmap-format-bit-order: {LeastSignificant, MostSignificant}
pixmap-formats: LISTofFORMAT
roots: LISTofSCREEN
keyboard: DEVICE
pointer: DEVICE
motion-buffer-size: CARD32
maximum-request-length: CARD16
where
FORMAT: [depth: CARD8,
bits-per-pixel: {4, 8, 16, 24, 32}
scanline-pad: {8, 16, 32}]
SCREEN: [root: WINDOW
device: DEVICE
width-in-pixels, height-in-pixels: CARD16
width-in-millimeters, height-in-millimeters: CARD16
allowed-depths: LISTofDEPTH
root-depth: CARD8
root-visual: VISUALID
default-colormap: COLORMAP
white-pixel, black-pixel: CARD32
min-installed-maps, max-installed-maps: CARD16
backing-stores: {Never, WhenMapped, Always}
save-unders: BOOL
current-input-masks: SETofEVENT]
DEPTH: [depth: CARD8
visuals: LISTofVISUALTYPE]
VISUALTYPE: [visual-id: VISUALID
class: {StaticGray, StaticColor, TrueColor,
GrayScale, PseudoColor, DirectColor}
red-mask, green-mask, blue-mask: CARD32
bits-per-rgb-value: CARD8
colormap-entries: CARD16]
Per server information:
The vendor string gives some indentification of the owner of the server
implementation. The semantics of the release-number is controlled by
the vendor.
The resource-id-mask contains a single contiguous set of bits (at least
18); the client allocates resource ids by choosing a value with (only)
some subset of these bits set, and ORing it with resource-id-base.
Only values constructed in this way can be used to name newly created
resources over this connection. Resource ids never have the top 3 bits
set. The client is not restricted to linear or contiguous allocation
of resource ids. Once an id has been freed, it can be reused, but this
should not be necessary. An id must be unique with respect to the ids
of all other resources, not just other resources of the same type.
Although the server is in general responsible for byte swapping data to
match the client, images are always transmitted and received in formats
(including byte order) specified by the server. The byte order for
images is given by image-byte-order, and applies to each scanline unit
in XYFormat (bitmap) format, and to each pixel value in ZFormat.
A bitmap is represented in scanline order. Each scanline is padded to
a multiple of bits as given by bitmap-format-scanline-pad. The pad
bits are of arbitrary value. The scanline is quantized in multiples of
bits as given by bitmap-format-scanline-unit. Within each unit, the
leftmost bit in the bitmap is either the least or most significant bit
in the unit, as given by bitmap-format-bit-order. If a pixmap is
represented in XYFormat, each plane is represented as a bitmap, and the
planes appear from most to least significant in bit order.
For each pixmap depth supported by some screen, pixmap-formats lists
the ZFormat used to represent images of that depth. In ZFormat, the
pixels are in scanline order, left to right within a scanline. The
number of bits used to hold each pixel is given by bits-per-pixel, and
may be larger than strictly required by the depth. When the
bits-per-pixel is 4, the order of nibbles in the byte is the same as
the image byte-order. Each scanline is padded to a multiple of bits as
given by scanline-pad.
How a pointing device roams the screens is up to the server
implementation, and is transparent to the protocol. No geometry among
screens is defined.
The server may retain the recent history of pointer motion, and to a
finer granularity than is reported by MotionNotify events. Such
history is available via the GetPointerMotions request. The
approximate size of the history buffer is given by motion-buffer-size.
Maximum-request-length specifies the maximum length of a request, in
4-byte units, accepted by the server; i.e., this is the maximum value
that can appear in the length field of a request. Requests larger than
this generate a Length error, and the server will read and simply
discard the entire request. Maximum-request-length will always be at
least 4096 (i.e., requests of length up to and including 16384 bytes
will be accepted by all servers).
Per screen information:
The allowed-depths specifies what pixmap and window depths are
supported. Pixmaps are supported for each depth listed, and windows of
that depth are supported if at least one visual type is listed for the
depth. A pixmap depth of one is always supported and listed, but
windows of depth one might not be supported. A depth of zero is never
listed, but zero-depth InputOnly windows are always supported.
Root-depth and root-visual specify the depth and visual type of the
root window. Width-in-pixels and height-in-pixels specify the size of
the root window (which cannot be changed). The class of the root
window is always InputOutput. Width-in-millimeters and
height-in-millimeters can be used to determine the physical size and
the aspect ratio.
The default-colormap is the one initially associated with the root
window. Clients with minimal color requirements creating windows of
the same depth as the root may want to allocate from this map by
default.
Black-pixel and white-pixel can be used in implementing a "monochrome"
application. These pixel values are for permanently allocated entries
in the default-colormap; the actual RGB values may be settable on some
screens.
The border of the root window is initially a pixmap filled with the
black-pixel. The initial background of the root window is a pixmap
filled with some unspecified two-color pattern using black-pixel and
white-pixel.
Min-installed-maps specifies the number of maps that can be guaranteed
to installed simultaneously (with InstallColormap), regardless of the
number of entries allocated in each map. Max-installed-maps specifies
the maximum number of maps that might possibly be installed
simultaneously, depending on their allocations. For the typical case
of a single hardware colormap, both values will be one.
Backing-stores indicates when the server supports backing stores for
this screen, although it may be storage limited in the number of
windows it can support at once. If save-unders is True, then the
server can support the save-under mode in CreateWindow and
ChangeWindowAttributes, although again it may be storage limited.
The current-input-events is what GetWindowAttributes would return for
the all-event-masks for the root window.
Per visual-type information:
A given visual type might be listed for more than one depth, or for
more than one screen.
For PseudoColor, a pixel value indexes a colormap to produce
independent RGB values; the RGB values can be changed dynamically.
GrayScale is treated the same as PseudoColor, except which primary
drives the screen is undefined, so the client should always store the
same value for red, green, and blue in colormaps. For DirectColor, a
pixel value is decomposed into separate RGB subfields, and each
subfield separately indexes the colormap for the corresponding value;
The RGB values can be changed dynamically. TrueColor is treated the
same as DirectColor, except the colormap has predefined read-only RGB
values, which are server-dependent, but provide (near-)linear ramps in
each primary. StaticColor is treated the same as PseudoColor, except
the colormap has predefined read-only RGB values, which are
server-dependent. StaticGray is treated the same as StaticColor,
except the red, green, and blue values are equal for any single pixel
value, resulting in shades of gray. StaticGray with a two-entry
colormap can be thought of as "monochrome".
The red-mask, green-mask, and blue-mask are only defined for
DirectColor and TrueColor; each has one contiguous set of bits, with no
intersections.
The bits-per-rgb-value specifies the log base 2 of the approximate
number of distinct color values (individually) of red, green, and blue.
Actual RGB values are always passed in the protocol within a 16-bit
spectrum.
The colormap-entries defines the number of available colormap entries
in a newly created colormap. For DirectColor and TrueColor, this will
usually be the size of an individual pixel subfield.
SECTION 10. REQUESTS
CreateWindow
wid, parent: WINDOW
class: {InputOutput, InputOnly, CopyFromParent}
depth: CARD8
visual: VISUALID or CopyFromParent
x, y: INT16
width, height, border-width: CARD16
value-mask: BITMASK
value-list: LISTofVALUE
Errors: IDChoice, Window, Pixmap, Colormap, Cursor, Match, Value, Alloc
Creates an unmapped window, and assigns the identifier wid to it.
A class of CopyFromParent means the class is taken from the parent. A
depth of zero for class InputOutput or CopyFromParent means the depth
is taken from the parent. A visual of CopyFromParent means the visual
type is taken from the parent. For class InputOutput, the visual type
and depth must be a combination supported for the screen (else a Match
error); the depth need not be the same as the parent, but the parent
must not be of class InputOnly (else a Match error). For class
InputOnly, the depth must be zero (else a Match error), and the visual
must be one supported for the screen (else a Match error), but the
parent may have any depth and class.
The server essentially acts as if InputOnly windows do not exist for
the purposes of graphics requests, exposure processing, and
VisibilityNotify events. An InputOnly window cannot be used as a
drawable (as a source or destination for graphics requests). InputOnly
and InputOutput windows act identically in other respects (properties,
grabs, input control, and so on).
The window is placed on top in the stacking order with respect to
siblings. The x and y coordinates are relative to the parent's origin,
and specify the position of the upper left outer corner of the window
(not the origin). The width and height specify the inside size, not
including the border, and must be non-zero. The border-width for an
InputOnly window must be zero (else a Match error).
The value-mask and value-list specify attributes of the window that are
to be explicitly initialized. The possible values are:
background-pixmap: PIXMAP or None or ParentRelative
background-pixel: CARD32
border-pixmap: PIXMAP or CopyFromParent
border-pixel: CARD32
bit-gravity: BITGRAVITY
win-gravity: WINGRAVITY
backing-store: {NotUseful, WhenMapped, Always}
backing-bit-planes: CARD32
backing-pixel: CARD32
save-under: BOOL
event-mask: SETofEVENT
do-not-propagate-mask: SETofDEVICEEVENT
override-redirect: BOOL
colormap: COLORMAP or CopyFromParent
cursor: CURSOR or None
The default values, when attributes are not explicitly initialized,
are:
background-pixmap: None
border-pixmap: CopyFromParent
bit-gravity: Forget
win-gravity: NorthWest
backing-store: NotUseful
backing-bit-planes: all ones
backing-pixel: zero
save-under: False
event-mask: {} (empty set)
do-not-propagate-mask: {} (empty set)
override-redirect: False
colormap: CopyFromParent
cursor: None
Only the following attributes are defined for InputOnly windows:
win-gravity, event-mask, do-not-propagate-mask, and cursor. It is a
Match error to specify any other attributes for InputOnly windows.
If background-pixmap is given, it overrides the default
background-pixel. The background pixmap and the window must have the
same root and the same depth (else a Match error). Any size pixmap can
be used, although some sizes may be faster than others. If background
None is specifed, the window has no defined background. If background
ParentRelative is specified, the parent's background is used, but the
window must have the same depth as the parent (else a Match error); if
the parent has background None, then the window will also have
background None. A copy of the parent's background is not made; the
parent's background is reexamined each time the window background is
required. If background-pixel is given, it overrides the default and
any background-pixmap given, and a pixmap of undefined size filled with
background-pixel is used for the background. For a ParentRelative
background, the background tile origin always aligns with the parent's
background tile origin; otherwise the background tile origin is always
the window origin.
When regions of the window are exposed and the server has not retained
the contents, the server automatically tiles the regions with the
window's background unless the window has a background of None, in
which case the previous screen contents are simply left in place.
Exposure events are then generated for the regions, even if the
background is None.
The border tile origin is always the same as the background tile
origin. If border-pixmap is given, it overrides the default
border-pixel. The border pixmap and the window must have the same root
and the same depth (else a Match error). Any size pixmap can be used,
although some sizes may faster than others. If CopyFromParent is
given, the parent's border pixmap is copied (subsequent changes to the
parent do not affect the child), but the window must have the same
depth as the parent (else a Match error). If border-pixel is given, it
overrides the default and any border-pixmap given, and a pixmap of
undefined size filled with border-pixel is used for the border.
Output to a window is always clipped to the inside of the window, so
that the border is never affected.
The bit-gravity defines which region of the window should be retained
if the window is resized, and win-gravity defines how the window should
be repositioned if the parent is resized; see ConfigureWindow.
A backing-store of WhenMapped advises the server that maintaining
contents of obscured regions when the window is mapped would be
beneficial. A backing-store of Always advises the server that
maintaining contents even when the window is unmapped would be
beneficial. Note that, even if the window is larger than its parent,
the server should maintain complete contents, not just the region
within the parent boundaries. If the server maintains contents,
Exposure events will not be generated, but the server may stop
maintaining contents at any time. A value of NotUseful advises the
server that maintaining contents is unnecessary, although a server may
still choose to maintain contents.
Backing-bit-planes indicates (with one bits) which bit planes of the
window hold dynamic data that must be preserved in backing-stores.
Backing-pixel specifies what value to use in planes not covered by
backing-bit-planes. The server is free to only save the specified bit
planes in the backing-store, and regenerate the remaining planes with
the specified pixel value.
If save-under is True, the server is advised that, when this window is
mapped, saving the contents of windows it obscures would be beneficial.
The event-mask defines which events the client is interested in for
this window (or, for some event types, inferiors of the window). The
do-not-propagate-mask defines which events should not be propagated to
ancestor windows when no client has the event type selected in this
window.
Override-redirect specifies whether map and configure requests on this
window should override a SubstructureRedirect on the parent, typically
to inform a window manager not to tamper with the window.
The colormap specifies the colormap, that best reflects the "true"
colors of the window. Servers capable of supporting multiple hardware
colormaps may use this information, and window managers may use it for
InstallColormap requests. The colormap must have the same visual type
as the window (else a Match error). If CopyFromParent is specified,
the parent's colormap is copied (subsequent changes to the parent do
not affect the child), but the window must have the same visual type as
the parent (else a Match error) and the parent must not have a colormap
of None (else a Match error).
If a cursor is specified, it will be used whenever the pointer is in
the window. If None is specified, the parent's cursor will be used
when the pointer is in the window, and any change in the parent's
cursor will cause an immediate change in the displayed cursor.
This request generates a CreateNotify event.
The background and border pixmaps and the cursor may be freed
immediately if no further explicit references to them are to be made.
Subsequent drawing into the background or border pixmap has an
undefined effect on the window state; the server might or might not
make a copy of the pixmap.
ChangeWindowAttributes
window: WINDOW
value-mask: BITMASK
value-list: LISTofVALUE
Errors: Window, Pixmap, Colormap, Cursor, Match, Value, Access
The value-mask and value-list specify which attributes are to be
changed. The values and restrictions are the same as for CreateWindow.
Changing the background does not cause the window contents to be
changed. Setting the border, or changing the background such that the
border tile origin changes, causes the border to be repainted.
Changing the background of a root window to None or ParentRelative
restores the default background pixmap. Changing the border of a root
window to CopyFromParent restores the default border pixmap.
Changing the win-gravity does not affect the current position of the
window.
Changing the backing-store of an obscured window to WhenMapped or
Always, or changing the backing-bit-planes, backing-pixel, or
save-under of a mapped window, may have no immediate effect.
Multiple clients can select input on the same window; their event-masks
are disjoint. When an event is generated it will be reported to all
interested clients. However, at most one client at a time can select
for SubstructureRedirect, at most one client at a time can select for
ResizeRedirect, and at most one client at a time can select for
ButtonPress.
There is only one do-not-propagate-mask for a window, not one per
client.
Changing the colormap of a window (i.e., defining a new map, not
changing the contents of the existing map) generates a ColormapNotify
event. Changing the colormap of a visible window may have no immediate
effect on the screen; see InstallColormap.
Changing the cursor of a root window to None restores the default
cursor.
The order in which attributes are verified and altered is server
dependent. If an error is generated, a subset of the attributes may
have been altered.
GetWindowAttributes
window: WINDOW
=>
visual: VISUALID
class: {InputOutput, InputOnly}
bit-gravity: BITGRAVITY
win-gravity: WINGRAVITY
backing-store: {NotUseful, WhenMapped, Always}
backing-bit-planes: CARD32
backing-pixel: CARD32
save-under: BOOL
colormap: COLORMAP or None
map-is-installed: BOOL
map-state: {Unmapped, Unviewable, Viewable}
all-event-masks, your-event-mask: SETofEVENT
do-not-propagate-mask: SETofDEVICEEVENT
override-redirect: BOOL
Errors: Window
Returns current attributes of the window. All-event-masks is the
inclusive-OR of all event masks selected on the window by clients.
Your-event-mask is the event mask selected by the querying client.
DestroyWindow
window: WINDOW
Errors: Window
If the argument window is mapped, an UnmapWindow request is performed
automatically. The window and all inferiors are then destroyed, and a
DestroyNotify event is generated for each window, in order from the
argument window downwards, with unspecified order among siblings at
each level.
Normal exposure processing on formerly obscured windows is performed.
If the window is a root window, this request has no effect.
DestroySubwindows
window: WINDOW
Errors: Window
Performs a DestroyWindow on all children of the window, in bottom to
top stacking order.
ChangeSaveSet
window: WINDOW
mode: {Insert, Delete}
Errors: Window, Match, Value
Adds or removes the specified window from the client's "save-set". The
window must have been created by some other client (else a Match
error). The use of the save-set is described in Section 11.
Windows are removed automatically from the save-set by the server when
they are destroyed.
ReparentWindow
window, parent: WINDOW
x, y: INT16
Errors: Window, Match
If the window is mapped, an UnmapWindow request is performed
automatically first. The window is then removed from its current
position in the hierarchy, and is inserted as a child of the specified
parent. The x and y coordinates are relative to the parent's origin,
and specify the new position of the upper left outer corner of the
window. The window is placed on top in the stacking order with respect
to siblings. A ReparentNotify event is then generated. The
override-redirect attribute of the window is passed on in this event; a
value of True indicates that a window manager should not tamper with
this window. Finally, if the window was originally mapped, a MapWindow
request is performed automatically.
Normal exposure processing on formerly obscured windows is performed.
The server might not generate exposure events for regions from the
initial unmap that are immediately obscured by the final map.
A Match error is generated if the new parent is not on the same screen
as the old parent, or if the new parent is the window itself or an
inferior of the window, or if the window has a ParentRelative
background and the new parent is not the same depth as the window.
MapWindow
window: WINDOW
Errors: Window
If the window is already mapped, this request has no effect.
If the override-redirect attribute of the window is False and some
other client has selected SubstructureRedirect on the parent, then a
MapRequest event is generated, but the window remains unmapped.
Otherwise, the window is mapped and a MapNotify event is generated.
If the window is now viewable and its contents had been discarded, then
the window is tiled with its background (if no background is defined,
the existing screen contents are not altered) and one or more exposure
events are generated. If a backing-store has been maintained while the
window was unmapped, no exposure events are generated. If a
backing-store will now be maintained, a full-window exposure is always
generated; otherwise only visible regions may be reported. Similar
tiling and exposure take place for any newly viewable inferiors.
MapSubwindows
window: WINDOW
Errors: Window
Performs a MapWindow request on all unmapped children of the window, in
top to bottom stacking order.
UnmapWindow
window: WINDOW
Errors: Window
If the window is already unmapped, this request has no effect.
Otherwise, the window is unmapped and an UnmapNotify event is
generated. Normal exposure processing on formerly obscured windows is
performed.
UnmapSubwindows
window: WINDOW
Errors: Window
Performs an UnmapWindow request on all mapped children of the window,
in bottom to top stacking order.
ConfigureWindow
window: WINDOW
value-mask: BITMASK
value-list: LISTofVALUE
Errors: Window, Match, Value
Changes the configuration of the window. The value-mask and value-list
specify which values are to be given. The possible values are:
x: INT16
y: INT16
width: CARD16
height: CARD16
border-width: CARD16
sibling: WINDOW
stack-mode: {Above, Below, TopIf, BottomIf, Opposite}
The x and y coordinates are relative to the parent's origin, and
specify the position of the upper left outer corner of the window. The
width and height specify the inside size, not including the border, and
must be non-zero. It is a Match error to attempt to make the
border-width of an InputOnly window non-zero.
If the override-redirect attribute of the window is False and some
other client has selected SubstructureRedirect on the parent, then a
ConfigureRequest event is generated, and no further processing is
performed. Otherwise, the following is performed.
If some other client has selected ResizeRedirect on the window and the
width or height of the window is being changed, then a ResizeRequest
event is generated, and the current width and height are used instead
in the following.
The geometry of the window is changed as specified and the window is
restacked among siblings as described below, and a ConfigureNotify
event is generated. If the width or height of the window has actually
changed, then children of the window are affected as described below.
Exposure processing is performed on formerly obscured windows.
Changing the width or height of the window causes its contents to be
moved or lost, depending on the bit-gravity of the window, and causes
children to be reconfigured, depending on their win-gravity. For a
change of width and height of W and H, we define the [x, y] pairs:
NorthWest: [0, 0]
North: [W/2, 0]
NorthEast: [W, 0]
West: [0, H/2]
Center: [W/2, H/2]
East: [W, H/2]
SouthWest: [0, H]
South: [W/2, H]
SouthEast: [W, H]
When a window with one of these bit-gravities is resized, the
corresponding pair defines the change in position of each pixel in the
window. When a window with one of these win-gravities has its parent
window resized, the corresponding pair defines the change in position
of the window within the parent. When a window is so repositioned, a
GravityNotify event is generated.
A gravity of Static indicates that the contents or origin should not
move relative to the origin of the root window. If the change in size
of the window is coupled with a change in position of [X, Y], then for
bit-gravity the change in position of each pixel is [-X, -Y], and for
win-gravity the change in position of a child when its parent is so
resized is [-X, -Y]. Note that Static gravity still only takes effect
when the width or height of the window is changed, not when the window
is simply moved.
A bit-gravity of Forget indicates that the window contents are always
discarded after a size change; the window is tiled with its background
(if no background is defined, the existing screen contents are not
altered) and one or more exposure events are generated. A server may
also ignore the specified bit-gravity and use Forget instead.
A win-gravity of Unmap is like NorthWest, but the child is also
unmapped when the parent is resized, and an UnmapNotify event is
generated.
If a sibling and a stack-mode is specified, the window is restacked as
follows:
Above: window is placed just above sibling
Below: window is placed just below sibling
TopIf: if sibling occludes window, then window is placed
at the top of the stack
BottomIf: if window occludes sibling, then window is
placed at the bottom of the stack
Opposite: if sibling occludes window, then window is placed at the
top of the stack, else if window occludes sibling, then
window is placed at the bottom of the stack
If a stack-mode is specified but no sibling is specified, the window is
restacked as follows:
Above: window is placed at the top of the stack
Below: window is placed at the bottom of the stack
TopIf: if any sibling occludes window, then window is placed at
the top of the stack
BottomIf: if window occludes any sibling, then window is placed at
the bottom of the stack
Opposite: if any sibling occludes window, then window is placed at
the top of the stack, else if window occludes any
sibling, then window is placed at the bottom of the stack
It is a Match error if a sibling is specified without a stack-mode, or
if the window is not actually a sibling.
Note that the computations for BottomIf, TopIf, and Opposite are
performed with respect to the window's final geometry (as controlled by
the other arguments to the request), not its initial geometry.
CirculateWindow
window: WINDOW
direction: {RaiseLowest, LowerHighest}
Errors: Window, Value
If some other client has selected SubstructureRedirect on the window,
then a CirculateRequest event is generated, and no further processing
is performed. Otherwise, the following is performed, and then a
CirculateNotify event is generated if the window is actually restacked.
For RaiseLowest, raises the lowest mapped child (if any) that is
occluded by another child to the top of the stack. For LowerHighest,
lowers the highest mapped child (if any) that occludes another child to
the bottom of the stack. Exposure processing is performed on formerly
obscured windows.
∂01-Jun-87 0531 RWS%ZERMATT.LCS.MIT.EDU@XX.LCS.MIT.EDU X protocol, part 6 of 6
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87 05:31:02 PDT
Received: from KILLINGTON.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 1 Jun 87 08:28-EDT
Date: Mon, 1 Jun 87 08:29 EDT
From: Robert Scheifler <RWS@ZERMATT.LCS.MIT.EDU>
Subject: X protocol, part 6 of 6
To: x3j13@sail.stanford.edu
Message-ID: <870601082914.1.RWS@KILLINGTON.LCS.MIT.EDU>
SetPointerMapping
map: LISTofCARD8
=>
status: {Success, Busy}
Errors: Value
Sets the mapping of the pointer. Elements of the list are indexed
starting from one. The length of the list must be the same as
GetPointerMapping would return. The index is a "core" button number,
and the element of the list defines the "effective" number.
A zero element disables a button, and elements are not restricted in
value by the number of physical buttons, but no two elements can have
the same non-zero value.
If any of the buttons to be altered are currently in the down state,
the status reply is Busy and the mapping is not changed.
GetPointerMapping
=>
map: LISTofCARD8
Errors: Value
Returns the current mapping of the pointer. Elements of the list are
indexed starting from one. The length of the list indicates the number
of physical buttons.
The nominal mapping for a pointer is the identity mapping; map[i]=i.
ChangePointerControl
do-acceleration, do-threshold: BOOL
acceleration-numerator, acceleration-denominator: INT16
threshold: INT16
Errors: Match, Value
Defines how the pointer moves. The acceleration is a multiplier for
movement, expressed as a fraction. For example, specifying 3/1 means
the pointer moves three times as fast as normal. The fraction may be
rounded arbitrarily by the server. Acceleration only takes effect if
the pointer moves more than threshold pixels at once, and only applies
to the amount beyond the threshold. Setting a value to -1 restores the
default. Other negative values generate a Value error, as does a zero
value for acceleration-denominator.
GetPointerControl
=>
acceleration-numerator, acceleration-denominator: CARD16
threshold: CARD16
Errors: Match
Returns the current acceleration and threshold for the pointer.
SetScreenSaver
timeout, interval: INT16
prefer-blanking: {Yes, No, Default}
allow-exposures: {Yes, No, Default}
Errors: Value
Timeout and interval are specified in minutes; setting a value to -1
restores the default. Other negative values generate a Value error.
If the timeout value is zero, screen-saver is disabled. If the timeout
value is non-zero, screen-saver is enabled. Once screen-saver is
enabled, if no input from the keyboard or pointer is generated for
timeout minutes, screen-saver is activated. For each screen, if
blanking is preferred and the hardware supports video blanking, the
screen will simply go blank. Otherwise, if either exposures are
allowed or the screen can be regenerated without sending exposure
events to clients, the screen is tiled with the root window background
tile, randomly re-origined each interval minutes if the interval value
is non-zero. Otherwise, the state of the screen does not change and
screen-saver is not activated. Screen-saver is deactivated, and all
screen states are restored, at the next keyboard or pointer input or at
the next ForceScreenSaver with mode Reset.
GetScreenSaver
=>
timeout, interval: CARD16
prefer-blanking: {Yes, No}
allow-exposures: {Yes, No}
Returns the current screen-saver control values.
ForceScreenSaver
mode: {Activate, Reset}
If the mode is Activate and screen-saver is currently deactivated, then
screen-saver is activated (even if screen-saver has been disabled with
a timeout value of zero). If the mode is Reset and screen-saver is
currently enabled, then screen-saver is deactivated (if it was
activated), and then the activation timer is reset to its initial
state, as if device input had just been received.
ChangeHosts
mode: {Insert, Delete}
host: HOST
Errors: Access, Value
Adds or removes the specified host from the access control list. When
the access control mechanism is enabled and a host attempts to
establish a connection to the server, the host must be in this list or
the server will refuse the connection.
The client must reside on the same host as the server, and/or have been
granted permission in the initial authorization at connection setup.
An initial access control list can be specified, typically by naming a
file that the server reads at startup and reset.
ListHosts
=>
mode: {Enabled, Disabled}
hosts: LISTofHOST
Returns the hosts on the access control list, and whether use of the
list at connection setup is currently enabled or disabled.
Each HOST is padded to a multiple of four bytes.
ChangeAccessControl
mode: {Enable, Disable}
Errors: Value, Access
Enables or disables the use of the access control list at connection
setups.
The client must reside on the same host as the server, and/or have been
granted permission in the initial authorization at connection setup.
ChangeCloseDownMode
mode: {Destroy, RetainPermanent, RetainTemporary}
Errors: Value
Defines what will happen to the client's resources at connection close.
A connection starts in Destroy mode. The meaning of the close-down
mode is described in Section 11.
KillClient
resource: CARD32 or AllTemporary
Errors: Value
If a valid resource is specified, forces a close-down of the client
that created the resource. If the client has already terminated in
either RetainPermanent or RetainTemporary mode, all of the client's
resources are destroyed (see Section 11). If AllTemporary is
specified, then the resources of all clients that have terminated in
RetainTemporary are destroyed.
NoOperation
This request has no arguments and no results, but the request length
field can be non-zero, allowing the request to be any multiple of 4
bytes in length. The bytes contained in the request are uninterpreted
by the server.
This request can be used in its minimum 4 byte form as "padding" where
necessary by client libraries that find it convenient to force requests
to begin on 64-bit boundaries.
SECTION 11. CONNECTION CLOSE
What happens at connection close:
All event selections made by the client are discarded. If the client
has the pointer actively grabbed, an UngrabPointer is performed. If
the client has the keyboard actively grabbed, an UngrabKeyboard is
performed. All passive grabs by the client are released. If the
client has the server grabbed, and UngrabServer is performed. If
close-down mode (see ChangeCloseDownMode) is RetainPermanent or
RetainTemporary, then all resources (including colormap entries)
allocated by the client are marked as "permanent" or "temporary",
respectively (but this does not prevent other clients from explicitly
destroying them). If the mode is Destroy, then all of the client's
resources are destroyed as described below.
What happens when a client's resources are destroyed:
For each window in the client's save-set, if the window is an inferior
of a window created by the client, the save-set window is reparented to
the closest ancestor such that the save-set window is not an inferior
of a window created by the client. If the save-set window is unmapped,
a MapWindow request is performed on it. After save-set processing, all
windows created by the client are destroyed. For each non-window
resource created by the client, the appropriate Free request is
performed. All colors and colormap entries allocated by the client are
freed.
What happens when the last connection to a server closes:
A server goes through a cycle, of having no connections and having some
connections. At every transition to the state of having no
connections, the server "resets" its state, as if it had just been
started. This starts by destroying all lingering resources from
clients that have terminated in RetainPermanent or RetainTemporary
mode. It additionally includes deleting all but the predefined atom
identifiers, deleting all properties on all root windows, resetting all
device maps and attributes (key click, bell volume, acceleration),
resetting the access control list, restoring the standard root tiles
and cursors, restoring the default font path, and restoring the input
focus to state PointerRoot.
SECTION 12. EVENTS
When a button is pressed with the pointer in some window W, and no active
pointer grab is in progress, then the ancestors of W are searched from the
root down, looking for a passive grab to activate. If no matching passive
grab on the button exists, then an active grab is started automatically for
the client receiving the event, and the last-pointer-grab time is set to the
current server time. The effect is essentially equivalent to a GrabButton
with arguments:
event-window: the event window
event-mask: the client's selected events on the event window
pointer-mode and keyboard-mode: Asynchronous
owner-events: True if the client has OwnerGrabButton selected on the
event window, else False
confine-to: None
cursor: None
The grab is terminated automatically when all buttons are released.
UngrabPointer and ChangeActiveGrab can both be used to modify the active grab.
KeyPress
and
KeyRelease
and
ButtonPress
and
ButtonRelease
and
MotionNotify
root, event: WINDOW
child: WINDOW or None
same-screen: BOOL
root-x, root-y, event-x, event-y: INT16
detail: <see below>
state: SETofKEYBUTMASK
time: TIMESTAMP
Generated when a key or button changes state, or the pointer moves.
The "source" of the event is the window the pointer is in. The window
with respect to which the event is normally reported is found by
looking up the hierarchy (starting with the source window) for the
first window on which any client has selected interest in the event,
provided no intervening window prohibits event generation by including
the event type in its do-not-propagate-mask. The actual window used
for reporting can be modified by active grabs and the focus window.
The window the event is reported with respect to is called the "event"
window.
Root is the root window of the "source" window, and root-x and root-y
are the pointer coordinates relative to root's origin at the time of
the event. Event is the "event" window. If the event window is on the
same screen as root, then event-x and event-y are the pointer
coordinates relative to the event window's origin; otherwise event-x
and event-y are zero. If the source window is an inferior of the event
window, then child is set to the child of the event window that is an
ancestor of the source window. The state component gives the state of
the buttons and modifier keys just before the event. The detail
component varies with the event type:
KeyPress, KeyRelease: KEYCODE
ButtonPress, ButtonRelease: BUTTON
MotionNotify: {Normal, Hint}
MotionNotify events are only generated when the motion begins and ends
in the window. The granularity of motion events is not guaranteed, but
a client selecting for motion events is guaranteed to get at least one
event when the pointer moves and comes to rest. Selecting
PointerMotion receives events independent of the state of the pointer
buttons. By selecting some subset of Button[1-5]Motion instead,
MotionNotify events will only be received when one or more of the
specified buttons are pressed. By selecting ButtonMotion, MotionNotify
events will received only when at least one button is pressed. The
events are always of type MotionNotify, independent of the selection.
If PointerMotionHint is selected, the server is free to send only one
MotionNotify event (with detail Hint) to the client for the event
window, until either the key or button state changes, or the pointer
leaves the event window, or the client issues a QueryPointer or
GetMotionEvents request.
EnterNotify
and
LeaveNotify
root, event: WINDOW
child: WINDOW or None
same-screen: BOOL
root-x, root-y, event-x, event-y: INT16
mode: {Normal, Grab, Ungrab}
detail: {Ancestor, Virtual, Inferior, Nonlinear, NonlinearVirtual}
focus: BOOL
state: SETofKEYBUTMASK
time: TIMESTAMP
If pointer motion causes the pointer to be in a different window than
before, EnterNotify and LeaveNotify events are generated instead of a
MotionNotify event. Only clients selecting EnterWindow on a window
receive EnterNotify events, and only clients selection LeaveNotify
receive LeaveNotify events. The pointer position reported in the event
is always the "final" position, not the "initial" position of the
pointer. In a LeaveNotify event, if a child of the event window
contains the "initial" position of the pointer, then the child
component is set to that child, otherwise it is None. For an
EnterNotify event, if a child of the event window contains the "final"
pointer position, then the child component is set to that child,
otherwise it is None. If the the event window is the focus window or
an inferior of the focus window, then focus is True, and otherwise
focus is False.
Normal pointer motion events have mode Normal; pseudo-motion events
when a grab actives have mode Grab, and pseudo-motion events when a
grab deactivates have mode Ungrab.
Normal events are generated as follows:
When the pointer moves from window A to window B, and A is an inferior
of B:
LeaveNotify with detail Ancestor is generated on A
LeaveNotify with detail Virtual is generated on each window between
A and B exclusive (in that order)
EnterNotify with detail Inferior is generated on B
When the pointer moves from window A to window B, and B is an inferior
of A:
LeaveNotify with detail Inferior is generated on A
EnterNotify with detail Virtual is generated on each window between
A and B exclusive (in that order)
EnterNotify with detail Ancestor is generated on B
When the pointer moves from window A to window B, with window C being
their least common ancestor:
LeaveNotify with detail Nonlinear is generated on A
LeaveNotify with detail NonlinearVirtual is generated on each window
between A and C exclusive (in that order)
EnterNotify with detail NonlinearVirtual is generated on each window
between C and B exclusive (in that order)
EnterNotify with detail Nonlinear is generated on B
When the pointer moves from window A to window B, on different screens:
LeaveNotify with detail Nonlinear is generated on A
LeaveNotify with detail NonlinearVirtual is generated on each window
above A up to and including its root (in order)
EnterNotify with detail NonlinearVirtual is generated on each window
from B's root down to but not including B (in order)
EnterNotify with detail Nonlinear is generated on B
When a pointer grab activates (but after any initial warp into a confine-to
window), with G the grab-window for the grab and P the window the pointer
is in:
EnterNotify and LeaveNotify events with mode Grab are generated (as for
Normal above) as if the pointer were to suddenly warp from its current
position in P to some position in G. However, the pointer does not
warp, and the pointer position is used as both the "initial" and
"final" positions for the events.
When a pointer grab deactivates, with G the grab-window for the grab and P
the window the pointer is in:
EnterNotify and LeaveNotify events with mode Ungrab are generated (as
for Normal above) as if the pointer were to suddenly warp from from
some position in G to its current position in P. However, the pointer
does not warp, and the current pointer position is used as both the
"initial" and "final" positions for the events.
FocusIn
and
FocusOut
event: WINDOW
mode: {Normal, WhileGrabbed, Grab, Ungrab}
detail: {Ancestor, Virtual, Inferior, Nonlinear, NonlinearVirtual,
Pointer, PointerRoot, None}
Generated when the input focus changes. Reported to clients selecting
FocusChange on the window. Events generated by SetInputFocus when the
keyboard is not grabbed have mode Normal; events generated by
SetInputFocus when the keyboard is grabbed have mode WhileGrabbed;
events generated when a keyboard grab actives have mode Grab, and
events generated when a keyboard grab deactivates have mode Ungrab.
Normal and WhileGrabbed events are generated as follows:
When the focus moves from window A to window B, and A is an inferior of B,
with the pointer in window P:
FocusOut with detail Ancestor is generated on A
FocusOut with detail Virtual is generated on each window between
A and B exclusive (in that order)
FocusIn with detail Inferior is generated on B
If P is an inferior of B, but P is not A or an inferior of A or an
ancestor of A, FocusIn with detail Pointer is generated on
each window below B down to and including P (in order)
When the focus moves from window A to window B, and B is an inferior of A,
with the pointer in window P:
If P is an inferior of A, but P is not A or an inferior of B or an
ancestor of B, FocusOut with detail Pointer is generated on
each window from P up to but not including A (in order)
FocusOut with detail Inferior is generated on A
FocusIn with detail Virtual is generated on each window between
A and B exclusive (in that order)
FocusIn with detail Ancestor is generated on B
When the focus moves from window A to window B, with window C being their
least common ancestor, and with the pointer in window P:
If P is an inferior of A, FocusOut with detail Pointer is generated on
each window from P up to but not including A (in order)
FocusOut with detail Nonlinear is generated on A
FocusOut with detail NonlinearVirtual is generated on each window
between A and C exclusive (in that order)
FocusIn with detail NonlinearVirtual is generated on each window
between C and B exclusive (in that order)
FocusIn with detail Nonlinear is generated on B
If P is an inferior of B, FocusIn with detail Pointer is generated on
each window below B down to and including P (in order)
When the focus moves from window A to window B, on different screens, with
the pointer in window P:
If P is an inferior of A, FocusOut with detail Pointer is generated on
each window from P up to but not including A (in order)
FocusOut with detail Nonlinear is generated on A
FocusOut with detail NonlinearVirtual is generated on each window
above A up to and including its root (in order)
FocusIn with detail NonlinearVirtual is generated on each window
from B's root down to but not including B (in order)
FocusIn with detail Nonlinear is generated on B
If P is an inferior of B, FocusIn with detail Pointer is generated on
each window below B down to and including P (in order)
When the focus moves from window A to PointerRoot (or None)
If P is an inferior of A, FocusOut with detail Pointer is generated on
each window from P up to but not including A (in order)
FocusOut with detail Nonlinear is generated on A
FocusOut with detail NonlinearVirtual is generated on each window
above A up to and including its root (in order)
FocusIn with detail PointerRoot (or None) is generated on all root
windows
When the focus moves from PointerRoot (or None) to window A:
FocusOut with detail PointerRoot (or None) is generated on all root
windows
FocusIn with detail NonlinearVirtual is generated on each window from
A's root down to but not including A (in order)
FocusIn with detail Nonlinear is generated on A
If P is an inferior of A, FocusIn with detail Pointer is generated on
each window below A down to and including P (in order)
When the focus moves from PointerRoot to None (or vice versa):
FocusOut with detail PointerRoot (or None) is generated on all root
windows
FocusIn with detail None (or PointerRoot) is generated on all root
windows
When a keyboard grab activates, with G the grab-window for the grab and F
the current focus:
FocusIn and FocusOut events with mode Grab are generated (as for Normal
above) as if the focus were to change from F to G
When a keyboard grab deactivates, with G the grab-window for the grab and F
the current focus:
FocusIn and FocusOut events with mode Ungrab are generated (as for
Normal above) as if the focus were to change from G to F
KeymapNotify
keys: LISTofCARD8
The value is a bit vector, as described in QueryKeymap. Reported to
clients selecting KeymapState on a window. Generated immediately after
every EnterNotify and FocusIn.
Expose
window: WINDOW
x, y, width, height: CARD16
last-in-series: BOOL
Reported to clients selecting Exposure on the window. Possibly
generated when a region of the window becomes viewable, but might only
be generated when a region becomes visible. All of the regions exposed
by a given "action" are guaranteed to be reported contiguously; if
last-in-series is False then another exposure follows.
The x and y coordinates are relative to drawable's origin, and specify
the upper left corner of a rectangule. The width and height specify
the extent of the rectangle.
Expose events are never generated on InputOnly windows.
GraphicsExposure
drawable: DRAWABLE
x, y, width, height: CARD16
last-in-series: BOOL
major-opcode: CARD8
minor-opcode: CARD16
Reported to clients selecting graphics-exposures in a graphics context.
Generated when a destination region could not be computed due to an
obscured or out-of-bounds source region. All of the regions exposed by
a given graphics request are guaranteed to be reported contiguously; if
last-in-series is False then another exposure follows.
The x and y coordinates are relative to drawable's origin, and specify
the upper left corner of a rectangule. The width and height specify
the extent of the rectangle.
The major and minor opcodes identify the graphics request used. For
the core protocol, major-opcode is always CopyArea or CopyPlane and
minor-opcode is always zero.
NoExposure
drawable: DRAWABLE
major-opcode: CARD8
minor-opcode: CARD16
Reported to clients selecting graphics-exposures in a graphics context.
Generated when a graphics request that might produce GraphicsExposure
events does not produce any. The drawable specifies the destination
used for the graphics request.
The major and minor opcodes identify the graphics request used. For
the core protocol, major-opcode is always CopyArea or CopyPlane and
minor-opcode is always zero.
VisibilityNotify
window: WINDOW
state: {Unobscured, PartiallyObscured, FullyObscured}
Reported to clients selecting VisibilityChange on the window. In the
following, the state of the window is calculated ignoring all of the
window's subwindows. When a window changes state from partially or
fully obscured or not viewable to viewable and completely unobscured,
an event with Unobscured is generated. When a window changes state
from a) viewable and completely unobscured or b) not viewable, to
viewable and partially obscured, an event with PartiallyObscured is
generated. When a window changes state from a) viewable and completely
unobscured or b) viewable and partially obscured or c) not viewable, to
viewable and fully obscured, an event with FullyObscured is generated.
VisibilityNotify events are never generated on InputOnly windows.
CreateNotify
parent, window: WINDOW
x, y: INT16
width, height, border-width: CARD16
override-redirect: BOOL
Reported to clients selecting SubstructureNotify on the parent.
Generated when the window is created. The arguments are as in the
CreateWindow request.
DestroyNotify
event, window: WINDOW
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when the
window is destroyed. "Event" is the window on which the event was
generated, and "window" is the window that is destroyed.
UnmapNotify
event, window: WINDOW
from-configure: BOOL
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when the
window changes state from mapped to unmapped. "Event" is the window on
which the event was generated, and "window" is the window that is
unmapped. The from-configure flag is True if the event was generated
as a result of the window's parent being resized when the window itself
had a win-gravity of Unmap.
MapNotify
event, window: WINDOW
override-redirect: BOOL
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when the
window changes state from unmapped to mapped. "Event" is the window on
which the event was generated, and "window" is the window that is
mapped. The override-redirect flag is from the window's attribute.
MapRequest
parent, window: WINDOW
Reported to the client selecting SubstructureRedirect on the parent.
Generated when a MapWindow request is issued on an unmapped window with
an override-redirect attribute of False.
ReparentNotify
event, window, parent: WINDOW
x, y: INT16
override-redirect: BOOL
Reported to clients selecting SubstructureNotify on either the old or
the new parent, and to clients selecting StructureNotify on the window.
Generated when the window is reparented. "Event" is the window on
which the event was generated, "window" is the window that has been
re-rooted, and "parent" specifies the new parent. The x and y
coordinates are relative to the new parent's origin, and specify the
position of the upper left outer corner of the window. The
override-redirect flag is from the window's attribute.
ConfigureNotify
event, window: WINDOW
x, y: INT16
width, height, border-width: CARD16
above-sibling: WINDOW or None
override-redirect: BOOL
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when a
ConfigureWindow request actually changes the state of the window.
"Event" is the window on which the event was generated, and "window" is
the window that is changed. If above-sibling is None, then the window
is on the bottom of the stack with respect to siblings; otherwise, the
window is immediately on top of the specified sibling. The
override-redirect flag is from the window's attribute.
GravityNotify
event, window: WINDOW
x, y: INT16
Reported to clients selecting SubstructureNotify on the parent, and to
clients selecting StructureNotify on the window. Generated when a
window is moved because of a change in size of the parent. "Event" is
the window on which the event was generated, and "window" is the window
that is moved.
ResizeRequest
window: WINDOW
width, height: CARD16
Reported to the client selecting ResizeRedirect on the window.
Generated when a ConfigureWindow request by some other client on the
window attempts to change the size of the window. The width and height
are the inside size, not including the border.
ConfigureRequest
parent, window: WINDOW
x, y: INT16
width, height, border-width: CARD16
above-sibling: WINDOW or None
Reported to the client selecting SubstructureRedirect on the parent.
Generated when a ConfigureWindow request is issued on the window by
some other client. The geometry is as derived from the request. The
above-sibling is the sibling the window should be placed directly on
top of; if None, then the window should be placed on the bottom.
CirculateNotify
event, window: WINDOW
place: {Top, Bottom}
Reported to clients selecting StructureNotify on the window, and to
clients selecting SubstructureNotify on the parent. Generated when the
window is actually restacked from a CirculateWindow request. "Event"
is the window on which the event was generated, and "window" is the
window that is restacked. If place is Top, the window is now on top of
all siblings; otherwise it is below all siblings.
CirculateRequest
parent, window: WINDOW
place: {Top, Bottom}
Reported to the client selecting SubstructureRedirect on the parent.
Generated when a CirculateWindow request is issued on the parent and a
window actually needs to be restacked. The window specifies the window
to be restacked, and place specifies what the new position in the
stacking order should be.
PropertyNotify
window: WINDOW
atom: ATOM
state: {NewValue, Deleted}
time: TIMESTAMP
Reported to clients selecting PropertyChange on the window. Generated
when a property of the window is changed. The timestamp indicates the
server time when the property was changed.
SelectionClear
owner: WINDOW
selection: ATOM
time: TIMESTAMP
Reported to the current owner of a selection. Generated on the window
losing ownership when a new owner is being defined. The timestamp is
the last-change time recorded for the selection.
SelectionRequest
owner: WINDOW
selection: ATOM
target: ATOM
property: ATOM or None
requestor: WINDOW
time: TIMESTAMP or CurrentTime
Reported to the owner of a selection. Generated when a client issues a
ConvertSelection request. The arguments are as in the request.
The owner should convert the selection based on the specified target
type. If a property is specified, the owner should store the result as
that property on the requestor window, and then send a SelectionNotify
event to the requestor using SendEvent. If the selection cannot be
converted as requested, the owner should send a SelectionNotify with
the property set to None.
SelectionNotify
requestor: WINDOW
selection, target: ATOM
property: ATOM or None
time: TIMESTAMP or CurrentTime
This event is only generated by clients using SendEvent. The owner of
a selection should send this event to a requestor when a selection has
been converted and stored as a property, or when a selection conversion
could not be performed (indicated with property None).
ColormapNotify
window: WINDOW
colormap: COLORMAP or None
new: BOOL
state: {Installed, Uninstalled}
Reported to clients selecting ColormapChange on the window. Generated
with value True for new when the colormap attribute of the window is
changed. Generated with value False for new when the colormap of a
window is installed or uninstalled. In either case, state indicates
whether the colormap is currently installed.
ClientMessage
window: WINDOW
type: ATOM
format: {8, 16, 32}
data: LISTofINT8 or LISTofINT16 or LISTofINT32
This event is only generated by clients using SendEvent. The type
specifies how the data is to be interpreted by the receiving client;
the server places no interpretation on the type or the data. The
format specifies whether the data should be viewed as a list of 8-bit,
16-bit, or 32-bit quantities, so that the server can correctly
byte-swap as necessary. The data always consists of either 20 8-bit
values or 10 16-bit values or 5 32-bit values, although particular
message types might not make use of all of these values.
SECTION 12. FLOW CONTROL AND CONCURRENCY
Whenever the server is writing to a given connection, it is permissible for
the server to stop reading from that connection (but if the writing would
block it must continue to service other connections). The server is not
required to buffer more than a single request per connection at one time. For
a given connection to the server, a client can block while reading from the
connection, but should undertake to read (events and errors) when writing
would block. Failure on the part of a client to obey this rule could result
in a deadlocked connection, although deadlock is probably unlikely unless the
transport layer has very little buffering, or unless the client attempts to
send large numbers of requests without ever reading replies or checking for
errors and events.
If a server is implemented with internal concurrency, the overall effect must
be as if individual requests are executed to completion in some serial order,
and that requests from a given connection are executed in delivery order
(i.e., the total execution order is a shuffle of the individual streams). The
"execution" of a request includes validating all arguments, collecting all
data for any reply, and generating (and queueing) all required events, but
does not include the actual transmission of the reply and the events. In
addition, the effect of any other "cause" (e.g., activation of a grab, pointer
motion) that can generate multiple events must effectively generate (and
queue) all required events indivisibly with respect to all other causes and
requests.